I'm working on a project with MassTransit publishing events (via RabbitMQ) that we denormalize into read models. Once a read model is generated/updated I publish another message that needs to make it to the client to update the UI. Enter SignalR. I had stupidly registered the handlers as lambdas in the hub constructor and quickly discovered that there are a lot of hub instances set up. :face palm:I think what I'm looking for is the web server(s) to be subscribed in a non-durable fanout exchange. A quick twitter conversation with Chris revealed that I need to mark those consumers as transient. https://twitter.com/PhatBoyG/status/306831977770790913Now, onto the questions:If this is the way to go, is there a way to configure all consumers registered in my container as transient? Every handler that my web instance declares would be transient.
I could be barking up the wrong tree with this approach from the get go. It looks like if I have multiple web servers each one needs to have it's own queue. Does anyone have any recommendations how this might work in a cloud environment where nodes can get spun up and down? It feels like I need a way to specify that the web server's queues are temporary.
Chris also recommended that I look at the SignalR backplane bits. With this approach, I wouldn't need any of the above. Instead, I could register the consumers on my worker like normal and poke the messages into SignalR endpoint via the c# client. I know the signalR scale out stuff is relatively new. I'm hoping someone might have some direction for me as to which direction I might want to take this.
Thank You,Josh--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/masstransit-discuss/-/kTXUzb7P61cJ.
For more options, visit https://groups.google.com/groups/opt_out.
I feel like with a lot of transient queues, subscriptions, you'll end up with a lot of junk that for some edge case doesn't get cleaned up. Over time this could be problematic. It is likely solvable, but doesn't mean it's easy.I don't know anything about SIgnalR, so I'm not help in regards to that. Well, I know what it is, but I haven't even looked at it.
-Travis
On Wed, Feb 27, 2013 at 5:47 PM, Dru Sellers <d...@drusellers.com> wrote:
On Wed, Feb 27, 2013 at 1:44 PM, Josh Bush <josh...@gmail.com> wrote:
I'm working on a project with MassTransit publishing events (via RabbitMQ) that we denormalize into read models. Once a read model is generated/updated I publish another message that needs to make it to the client to update the UI. Enter SignalR. I had stupidly registered the handlers as lambdas in the hub constructor and quickly discovered that there are a lot of hub instances set up. :face palm:I think what I'm looking for is the web server(s) to be subscribed in a non-durable fanout exchange. A quick twitter conversation with Chris revealed that I need to mark those consumers as transient. https://twitter.com/PhatBoyG/status/306831977770790913Now, onto the questions:If this is the way to go, is there a way to configure all consumers registered in my container as transient? Every handler that my web instance declares would be transient.I would suggest implementing your own 'scan' method that does this. its not a lot of code to do and would give you the level of control you wantI could be barking up the wrong tree with this approach from the get go. It looks like if I have multiple web servers each one needs to have it's own queue. Does anyone have any recommendations how this might work in a cloud environment where nodes can get spun up and down? It feels like I need a way to specify that the web server's queues are temporary.rabbitmq has a temporary queue name concept, that we probably don't easily expose but could. then there is another switch in rabbitmq i believe that will tear down the bindings when it goes away. Might be interesting.Chris also recommended that I look at the SignalR backplane bits. With this approach, I wouldn't need any of the above. Instead, I could register the consumers on my worker like normal and poke the messages into SignalR endpoint via the c# client. I know the signalR scale out stuff is relatively new. I'm hoping someone might have some direction for me as to which direction I might want to take this.all chris here
Thank You,Josh
--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/masstransit-discuss/-/kTXUzb7P61cJ.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/masstransit-discuss/-/kI5--GhVgokJ.
--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/masstransit-discuss/-/2aQl7Ahw4iIJ.