Alexis <br><br>When are you planning to release version for first option?<br><br>Can you explain the second option?<br><br>Thanks<br>Gagan<br><br><div class="gmail_quote">On Mon, Jul 6, 2009 at 11:06 PM, Alexis Richardson <span dir="ltr"><<a href="mailto:alexis.richardson@gmail.com">alexis.richardson@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Gagan<br>
<br>
One way to simplify the subscription management and get rid of 'heavy'<br>
churn, is to use "exchange to exchange" bindings. �These are something<br>
we have looked at - I am just checking with the guys to find out of<br>
this solution would work well, and if so then when it will appear.<br>
<br>
Another option would be to create a custom exchange which used<br>
presence to 'show' and 'hide' queue bindings. �This would be quite<br>
neat, but it would involve some coding.<br>
<font color="#888888"><br>
alexis<br>
</font><div><div></div><div class="h5"><br>
<br>
On Sat, Jul 4, 2009 at 8:07 PM, GAGAN ARORA<<a href="mailto:gaganarora.itm@gmail.com">gaganarora.itm@gmail.com</a>> wrote:<br>
> Alexis,<br>
><br>
> Thanks for your wonderful support and solutions.<br>
><br>
> Firstly answers to your queries:<br>
><br>
> 1. Are you using fanout exchanges for this (if you want one exchange<br>
> per user, then the answer should be 'yes').<br>
><br>
>>> No I am using topic exchanges because there will be three type of<br>
>>> bindings of a queue with an excajnde. One for publishing messages to all<br>
>>> users, another for one to one messaging and third for publishing message to<br>
>>> a set of users.<br>
><br>
> 2. Where is the RabbitMQ server running? �Is it on Server 1 or 2, or<br>
> is it on a 3rd server? �It may not be that important but it would be<br>
> good to know.<br>
><br>
>>> RabbitMQ Server is running on 3rd Server.<br>
><br>
><br>
> Back to original problem.<br>
><br>
> Actually I thought of the solution provided by you before posting the query<br>
> to you. But if I follow this solution I have to perform following steps<br>
> whenever a user comes online:<br>
> 1. Create a queue.<br>
> 2. Create a binding of newly created queue with all exchanges of other users<br>
> for retrieving messages published by other users.<br>
> 3. Creating a binding with exchange of all users for one to one messaging.<br>
> 4. Create a binding with exchanges of a set of users.<br>
><br>
> When user goes offline following operation is to be performed:<br>
> 1. Delete all the existing bindings of a queue.<br>
> 2. Deleting the queue.<br>
><br>
> Actually I want my online and offline processes light weighted. According to<br>
> me this solution would have a high impact on performance and will increase<br>
> time to come online and offline.<br>
><br>
> Kindly let me know if this can be achieved in some other manner.<br>
><br>
> Thanks<br>
> Gagan Arora<br>
><br>
><br>
><br>
><br>
><br>
> On Sat, Jul 4, 2009 at 3:23 PM, Alexis Richardson<br>
> <<a href="mailto:alexis.richardson@gmail.com">alexis.richardson@gmail.com</a>> wrote:<br>
>><br>
>> Gagan,<br>
>><br>
>> Hi - thank-you for sending the diagram and information which was very<br>
>> useful. �There are several ways to implement the 'twitter style'<br>
>> pattern that you have described. �See below for one way to do it that<br>
>> illustrates the AMQP model. �It may not be the most efficient solution<br>
>> in terms of performance as I shall point out.<br>
>><br>
>> Two quick questions:<br>
>><br>
>> 1. Are you using fanout exchanges for this (if you want one exchange<br>
>> per user, then the answer should be 'yes').<br>
>><br>
>> 2. Where is the RabbitMQ server running? �Is it on Server 1 or 2, or<br>
>> is it on a 3rd server? �It may not be that important but it would be<br>
>> good to know.<br>
>><br>
>> OK - to your cases -<br>
>><br>
>> Case1: User B sending his message to UserB Exchange which will route<br>
>> message to User A queue but User A is not connected to any of servers.<br>
>> At this point of �all messages sent to Queue A should be dropped.<br>
>><br>
>> >>> One way to do this is to identify the lifecycle of Queue A with the<br>
>> >>> presence of User A on servers 1 and 2. �In other words, when User A is not<br>
>> >>> connected to server 1, and also not connected to server 2, then Queue A does<br>
>> >>> not exist. �Note - This is not the only way to achieve what you want but it<br>
>> >>> may be the least fiddly :-)<br>
>><br>
>> Case2: User A connected to server 1 but UserA consumer is not yet<br>
>> subscribed to UserA queue. If UserB sends any message to its exchange<br>
>> which is routed to Queue of UserA. At this moment of time I want all<br>
>> messages to be stored in queue.<br>
>><br>
>> >>> One way to do this (continuing from the above) is to create Queue A<br>
>> >>> immediately after UserA connects to server 1. �This is an action that server<br>
>> >>> 1 can initiate on behalf of UserA. �After Queue A has been created, then it<br>
>> >>> should be bound to all exchanges from which it will receive messages, such<br>
>> >>> as UserB's exchange. �This will then have the stated effect you seek "If<br>
>> >>> UserB sends any message to its exchange [it] is routed to Queue of UserA.".<br>
>> >>> �Also, because UserA's consumer has not yet started consuming messages from<br>
>> >>> Queue A, the messages will all remain stored in the queue.<br>
>><br>
>> >>> In addition, if instead of proceeding to Case 3, we revert to Case 1,<br>
>> >>> for example User A disconnects from Server 1, then Queue A can simply be<br>
>> >>> deleted (along with its contents). �(See also Case 5 below)<br>
>><br>
>> >>> However - while simple, the above is possibly not the most performant<br>
>> >>> solution if (a) you are running RabbitMQ in clustered mode and (b) your<br>
>> >>> Users generally follow a lot of other Users and (c) they connect and<br>
>> >>> disconnect frequently. �This is because the effect of (c) is to frequuently<br>
>> >>> update the routing table, possibly with a lot of binding/routing data (b),<br>
>> >>> and then replicating it across the cluster (a).<br>
>><br>
>> >>> Let us know if you want more info about other ways to do this.<br>
>><br>
>><br>
>> Case3: User A is connected to both servers and UserA consumer is<br>
>> subscribed to UserA queue. If UserB sends any message to its exchange<br>
>> which is routed to Queue of UserA. At this moment of time I want all<br>
>> messages stored in queue to be delievered plus any other incoming<br>
>> message should also be routed.<br>
>><br>
>> >>> In any case, to achieve this, just start consuming messages from Queue<br>
>> >>> A.<br>
>><br>
>> >>> I assume by 'delivered', you mean 'delivered to UserA's consumer'.<br>
>> >>> �Where is that running?<br>
>><br>
>><br>
>><br>
>><br>
>> Case4: User A is connected to both servers and UserA consumer is<br>
>> subscribed to UserA queue. Now User disconnects from Server 2. If<br>
>> UserB sends any message to its exchange which is routed to Queue of<br>
>> UserA. Again I want to store all messages.<br>
>><br>
>> >>> To achieve this, just stop consuming messages from Queue A. �They will<br>
>> >>> be stored in Queue A.<br>
>><br>
>><br>
>><br>
>> Case5: If user A is disconnected from both servers. Initial state is<br>
>> achieved again.<br>
>><br>
>> >>> When User A disconnects from Server 1, then Server 1 can tell RabbitMQ<br>
>> >>> to delete Queue A (along with its contents)<br>
>><br>
>> Cheers,<br>
>><br>
>> alexis<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Fri, Jul 3, 2009 at 5:05 PM, GAGAN ARORA<<a href="mailto:gaganarora.itm@gmail.com">gaganarora.itm@gmail.com</a>><br>
>> wrote:<br>
>> > Hi Alexis<br>
>> > Attaching a doc having architecture diagram and cases desired. Hope this<br>
>> > would make things more clear to you.<br>
>> > Thanks<br>
>> > Gagan Arora<br>
>> ><br>
>> > On Fri, Jul 3, 2009 at 8:23 PM, Alexis Richardson<br>
>> > <<a href="mailto:alexis.richardson@gmail.com">alexis.richardson@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Gagan,<br>
>> >><br>
>> >> I'm a bit confused about what you are trying to do. �I think what you<br>
>> >> describe is possible but I am not sure what role is being played by<br>
>> >> your two servers. �Is RabbitMQ running on both of them, one of them,<br>
>> >> or neither? �You may find it easier to just use one RabbitMQ server.<br>
>> >><br>
>> >> Can you send a drawing of what your desired configuration is?<br>
>> >><br>
>> >> alexis<br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Fri, Jul 3, 2009 at 3:08 PM, GAGAN ARORA<<a href="mailto:gaganarora.itm@gmail.com">gaganarora.itm@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > Hi<br>
>> >> > I am developing a system in which a user will connect to two servers.<br>
>> >> > On<br>
>> >> > connecting to first server he will become online and will send his<br>
>> >> > presence<br>
>> >> > update but he will receive presence updates only once he is connected<br>
>> >> > to<br>
>> >> > other server as his consumer subscribes to his queue after connecting<br>
>> >> > to<br>
>> >> > second server.<br>
>> >> > I am using one exchange and one queue per user. So if one user comes<br>
>> >> > online<br>
>> >> > then he will send his presence update to his exchange and users bound<br>
>> >> > to<br>
>> >> > that will receive updates.<br>
>> >> > I need to configure a queue which would hold messages for user who<br>
>> >> > has<br>
>> >> > just<br>
>> >> > came online until he is connected to other server. After connecting<br>
>> >> > to<br>
>> >> > second server all messages will be consumed. All messages sent to<br>
>> >> > queue<br>
>> >> > will<br>
>> >> > be dropped once user goes offline.<br>
>> >> > Is it possible?<br>
>> >> > Thanks<br>
>> >> > Gagan Arora<br>
>> >> > _______________________________________________<br>
>> >> > rabbitmq-discuss mailing list<br>
>> >> > <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
>> >> > <a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
>> >> ><br>
>> >> ><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br>