[rabbitmq-discuss] Messages Timeout in Queue

[Alexis Richardson]

On Tue, Jul 7, 2009 at 5:39 AM, GAGAN ARORA<gaganarora.itm at gmail.com> wrote:
> Alexis
> But my design says queue must be  bind to an exchange when user is created
> and not at time User connects to server 1.

If so, then that information is not in the document you sent.  You
will see that the queue binding has to happen between Case 1 (when
messages are dropped) and Case 2 (when messages are queued).

In your design doc, how does Case 5 arise?  It looks like User A is
disconnecting from both servers, but not getting destroyed.  I suggest
you use this mechanism to avoid remaining in the state 'Case 4' for
unbounded periods of time.  That way, you won't need TTL.

alexis














> Gagan
>
> On Tue, Jul 7, 2009 at 2:25 AM, Alexis Richardson
> <alexis.richardson at gmail.com> wrote:
>>
>> On Mon, Jul 6, 2009 at 8:17 PM, GAGAN ARORA<gaganarora.itm at gmail.com>
>> wrote:
>> > Alexis
>> >
>> > Actually dropping out messages from queue is another problem I am facing
>> > and
>> > is following it on another thread with you. In this case I am assuming
>> > there
>> > is no dropping  out of messages from queue if there is no consumer is
>> > listening to the queue and a message is always queued up in queue.
>>
>> Messages will get dropped by an exchange X instead of being put in a
>> queue Q, when Q is not bound to X.
>>
>> So to go through your case:
>>
>> "Case1: User B sending his message to UserB Exchange which will route
>> message to User A queue but User A is not connected to any of servers.
>>  At this point of  all messages sent to Queue A should be dropped."
>>
>> The property you want is:
>>
>> * When User A is not connected to any of servers
>> * Then all messages sent to Queue A should be dropped
>>
>> This is true IF when User A is not connected to any of the servers,
>> THEN queue A is not bound to any exchanges.
>>
>> This has *nothing* to do with consumers or what they are 'listening' to.
>>
>> So - when User A is not connected then (if above) messages for A get
>> dropped.  Easy peasy.
>>
>> alexis
>>
>>
>>
>>
>>
>> > Thanks
>> > Gagan
>> >
>> > On Tue, Jul 7, 2009 at 12:03 AM, Alexis Richardson
>> > <alexis.richardson at gmail.com> wrote:
>> >>
>> >> Gagan,
>> >>
>> >> On Mon, Jul 6, 2009 at 7:02 PM, GAGAN ARORA<gaganarora.itm at gmail.com>
>> >> wrote:
>> >> > Alexis
>> >> >
>> >> > a) when the User A is not logged into server 1 or server 2, any
>> >> > messages sent to them by User B are discarded
>> >> >>> Actually during this case no consumer would be listening to User A
>> >> >>> queue
>> >> >>> and hence the messages can't be discarded and would be queued in
>> >> >>> Queue.
>> >>
>> >> In your document you said:
>> >>
>> >> "Case1: User B sending his message to UserB Exchange which will route
>> >> message to User A queue but User A is not connected to any of servers.
>> >> At this point of  all messages sent to Queue A should be dropped."
>> >>
>> >> If this is happening then the messages will be discarded and not
>> >> queued in Queue.
>> >>
>> >> alexis
>> >>
>> >>
>> >>
>> >> > b) but, when User A is logged in to server 1, any messages sent by
>> >> > User B that may be routed to User A are queued in Queue A,
>> >> >>> No of messages increases.
>> >> >
>> >> > c) .... delivered when User A logs into server 2.
>> >> >>> A large no of messages get delieverd.
>> >> >
>> >> > It is a constraint in my system that I have to initialize consumer
>> >> > when
>> >> > User
>> >> > A connects to Server2.
>> >> >
>> >> > On Mon, Jul 6, 2009 at 9:28 PM, Alexis Richardson
>> >> > <alexis.richardson at gmail.com> wrote:
>> >> >>
>> >> >> Gagan
>> >> >>
>> >> >> As I understood from your document:
>> >> >>
>> >> >> a) when the User A is not logged into server 1 or server 2, any
>> >> >> messages sent to them by User B are discarded
>> >> >> b) but, when User A is logged in to server 1, any messages sent by
>> >> >> User B that may be routed to User A are queued in Queue A, and then
>> >> >> ...
>> >> >> c) .... delivered when User A logs into server 2.
>> >> >>
>> >> >> Provided that you can implement this efficiently (see other email)
>> >> >> then the consumer at User A only needs to discard messages that are
>> >> >> older than one minute, and that were not already discarded due to
>> >> >> (a)
>> >> >> above.  So unless the time interval between A logging into server 1,
>> >> >> and A logging into server 2, is "quite long" then the 'timestamp'
>> >> >> method adds very little overhead.
>> >> >>
>> >> >> Is that correct or have I missed something?
>> >> >>
>> >> >> alexis
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Sat, Jul 4, 2009 at 8:28 PM, GAGAN
>> >> >> ARORA<gaganarora.itm at gmail.com>
>> >> >> wrote:
>> >> >> > Hi Alexis
>> >> >> >
>> >> >> > My system is similar to an IM system and is using RabbitMQ for
>> >> >> > presence
>> >> >> > updates and have designed it in such a way that a consumer
>> >> >> > subscribes
>> >> >> > to
>> >> >> > a
>> >> >> > queue only when it comes online.Now the issue is as stated by you
>> >> >> > there
>> >> >> > will
>> >> >> > be a large no of messages ready to be deleivered when a user comes
>> >> >> > online.
>> >> >> > Checking timestamp for each message will result in high cost.
>> >> >> >
>> >> >> > There can be a solution in which a message can be published using
>> >> >> > immediate
>> >> >> > flag. But it is desired by consumer to get all messages which are
>> >> >> > less
>> >> >> > than
>> >> >> > 1 minute old.
>> >> >> >
>> >> >> > Can you suggest some other solution for achieving this?
>> >> >> >
>> >> >> > Thanks
>> >> >> > Gagan Arora
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Sat, Jul 4, 2009 at 3:32 PM, Alexis Richardson
>> >> >> > <alexis.richardson at gmail.com> wrote:
>> >> >> >>
>> >> >> >> Gagan,
>> >> >> >>
>> >> >> >> On Fri, Jul 3, 2009 at 5:08 PM, GAGAN
>> >> >> >> ARORA<gaganarora.itm at gmail.com>
>> >> >> >> wrote:
>> >> >> >> > Hi Alexis
>> >> >> >> > The problem statement here is I dont want my messages in queue
>> >> >> >> > for
>> >> >> >> > more
>> >> >> >> > than
>> >> >> >> > 1 minute.
>> >> >> >>
>> >> >> >> The easiest way to do this is for the client to keep consuming
>> >> >> >> the
>> >> >> >> messages from the queue.
>> >> >> >>
>> >> >> >> However: presumably you want messages to be ignored in the case
>> >> >> >> where
>> >> >> >> (a) there is no consumer to get the messages from the queue; and
>> >> >> >> (b)
>> >> >> >> the messages are more than one minute old.
>> >> >> >>
>> >> >> >> If so then: Have you considered putting a timestamp on the
>> >> >> >> messages?
>> >> >> >> That way, when a consumer starts taking messages from the queue,
>> >> >> >> it
>> >> >> >> can simply check the timestamps and throw away anything 'old'.
>> >> >> >>  This
>> >> >> >> solution works just fine when (i) you don't need real time
>> >> >> >> accuracy
>> >> >> >> ie. "about a minute" is just as good as "exactly a minute", and
>> >> >> >> provided that (ii) there aren't too many messages to throw away.
>> >> >> >> Judging by the document that you sent, both (i) and (ii) are
>> >> >> >> true.
>> >> >> >>
>> >> >> >> Does this help?
>> >> >> >>
>> >> >> >> alexis
>> >> >> >>
>> >> >> >>
>> >> >> >> > I have tried expiration property while publishing a message but
>> >> >> >> > later came to know that it is still not implemented. Can you
>> >> >> >> > help
>> >> >> >> > me
>> >> >> >> > out
>> >> >> >> > in
>> >> >> >> > figuring some alternate approach?
>> >> >> >> > Thanks
>> >> >> >> > Gagan Arora
>> >> >> >> >
>> >> >> >> > On Fri, Jul 3, 2009 at 8:17 PM, Alexis Richardson
>> >> >> >> > <alexis.richardson at gmail.com> wrote:
>> >> >> >> >>
>> >> >> >> >> Gagan,
>> >> >> >> >>
>> >> >> >> >> On Fri, Jul 3, 2009 at 3:10 PM, GAGAN
>> >> >> >> >> ARORA<gaganarora.itm at gmail.com>
>> >> >> >> >> wrote:
>> >> >> >> >> > Hi
>> >> >> >> >> > Is it possible to set message time out in Java client API,
>> >> >> >> >> > so
>> >> >> >> >> > that
>> >> >> >> >> > messages
>> >> >> >> >> > drop out from queue after some interval of time if nobody
>> >> >> >> >> > consumes
>> >> >> >> >> > it?.
>> >> >> >> >>
>> >> >> >> >> Not yet but this is a feature have been asking for quite a
>> >> >> >> >> bit.
>> >> >> >> >>  It's
>> >> >> >> >> on our roadmap.
>> >> >> >> >>
>> >> >> >> >> There may be other ways to achieve what you want.
>> >> >> >> >>
>> >> >> >> >> alexis
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> > Thanks
>> >> >> >> >> > Gagan Arora
>> >> >> >> >> > _______________________________________________
>> >> >> >> >> > rabbitmq-discuss mailing list
>> >> >> >> >> > rabbitmq-discuss at lists.rabbitmq.com
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>