# of elements in queue

[crossrulz]

---

@Eric1977 wrote:

---

@crossrulz wrote:

You really shouldn't be looking at the number of elements left in order to determine whether or not to stop.

---

May I ask why? Isn't the elements left telling me how many processes are left in the consumer loop?

---

You can't say that for sure.  Keep in mind that the producer is adding to the queue as you process them in the consumer.  So you could run into a weird situation where the consumer has processed all the elements in the queue but the producer still isn't done adding to it.

Thinking about this a little more, another option is to use a loop after the producer is complete.  This loop would check the number of elements left in the queue.  When the queue is empty, release the queue.  The resulting error will stop the consumer loop.  Regardless, you should not be stopping the consumer loop with the stop button.

[Brandyn]

What happens when the application is idle or first starts up? It will be 0 in both those cases.

[Eric1977]

---

@Brandyn wrote:

What happens when the application is idle or first starts up? It will be 0 in both those cases.

---

You are right, it will be zero. I think GerdW's or crossrulz comment about switching from an OR to a AND solved that issue.

[Mark_Yedinak · Accepted solution]

Looking at the number of elements in the queue besides what has been mentioned also turns your system into a polling system. You start to lose the benefits of an event driven system. I don't like to use queue with "unnamed" message types. Nearly all of my queues use a basic command element which consists of a message ID and the data. Explicit messages makes the system more robust and flexible and it also makes the code easier to understand. It is very clear that a Stop message stops a process.

[Eric1977]

Now that I think about this more, I think Brandyn's & crossrulz are on the right track. I'm not placing a rule if the producer isn't putting anything into the queue and is in a idle state. I'm wondering if, using crossrulz theory of wiring the error wire to the stop button after the dequeue and leave the stop button on the consumer producer?

[Brandyn]

Well Mark is bringing up a good point.  Right now you are running into a synchronization issue and you are polling.  If you are going to use the producer consumer design pattern, then your consumer loop should be a state machine and the message you pass should contain a messeage ID and data.  

[Mark_Yedinak]

I still recommend explicit messaging to control when things start/stop/exit etc. I will admit that generally the only error I ever get out of a dequeue is the error generated when the queue is destroyed but explicit messaging makes the code much easier to understand.

[Brandyn]

You will need to define some messages such as a Stop message and Wirite to Database message. When you press the Stop button you would enqueue the stop message, when you want to send data you send the Database Message, else you do not do anything and you sit idle not polling. 

[crossrulz]

Have we beat in the notion of using a messaging system enough yet?  To create your message ID, I would recommend adding a string to your cluster.  On the consumer side, you then have a case structure to handle each of the message IDs, including a default of an invalid message ID.

[Brandyn]

Didnt click refresh before posting the comment.