On Thu, Apr 3, 2008 at 12:19 AM, Arjen van der Meijden <
[EMAIL PROTECTED]> wrote:
> My consumer just consumes a message, processes it and then goes on waiting
> for another one. So if that message happens to be a 'kill'-message, it dies
> (if the message was sent after the consumer started).
>
>
On 3-4-2008 8:50, Joel Poloney wrote:
Is your "kill"-message on every call? Or is that only when you manually
interrupt it? I'm wondering if you changed the Stomp-implementation such
that if you've consumed all of the messages (and it's waiting for a new
message to come through), it automatically
On Wed, Apr 2, 2008 at 11:39 PM, Arjen van der Meijden <
[EMAIL PROTECTED]> wrote:
> I would go with 1. But you may want to add some control-code to ensure you
> can easily and cleanly kill your scripts. In my code, I added a few signal
> handlers, so the consumer first finishes its most recent jo
On 3-4-2008 7:47, Joel Poloney wrote:
1. I have a consumer in a while(1) { //consume } fashion. That would
basically run forever. As I understand it, this is the way most web servers
work (at the core, core level). In this model, I would have to make sure
that the consumer was always running (per
List,
I'm new to message queues, but I generally understand the concept. I've been
playing with ActiveMQ this afternoon using the PHP Stomp client to make
requests. I noticed that in the Stomp client you don't have access to any
given queue size, whereas in the JMS API I have access to these numbe
