I'm still trying to get my head around the way rhino models queues and how Amazon SQS works. Can you clarify what would happen if there are multiple one-way busses that issue the same message type? For example, imagine N web servers that want to enqueu a message to send an email to a new user. M subscribers would be set up to read from that queue and send the emails.
If I were writing this raw in SQS, I'd just serialize the messages on each of the N web servers and put them in the same queue. Each of the M subscribers would pull them out via queries that specify the type(s) they will accept (so there is no real "subscription"). An external tool would monitor for an excessive backlog of messages I'm not sure how I'd configure that in Rhino. Would I need two one-way machines, each publishing to their own local queue, then some sort of load balancer in between those queues and the subscribers? Or would each machine push to the same queue? Would the subscribers each connect to the publishers directly, or would they go through an intermediary. Then what steps would I need to go through to scale up to N+1 and M+1? Thanks! On Wed, Nov 23, 2011 at 6:00 PM, Corey Kaylor <[email protected]> wrote: > Providing an abstraction of some sort like IPublishMessages would be > preferable over losing the behavior altogether for this one transport. > > > On Wed, Nov 23, 2011 at 6:44 PM, John Duddy <[email protected]> wrote: > >> Having the transports in their own assemblies would be great. It took me >> awhile to figure out the touch points from the two existing transports. >> >> So, would it be an unacceptable change in the metaphor to do away with >> the subscription tracking for this one transport type, since subscribers >> and publishers can be running at non-overlapping times? >> >> >> On Wed, Nov 23, 2011 at 5:38 PM, Corey Kaylor <[email protected]> wrote: >> >>> You would need to implement and register an ITransport. >>> >>> There are no assumptions for "local reliable queues", just no >>> implementations otherwise. >>> >>> If you invoke bus.Publish instead of bus.Notify the bus will throw when >>> there are no subscribers. >>> >>> For subscriptions you would need to implement and register an >>> ISubscriptionStorage. >>> >>> Nothing else you've said sounds off or incorrect. >>> >>> In V3 I plan to split out transports other than the MSMQ transport >>> (possibly subscription storage) into their own assemblies. I won't begin >>> work on this until January timeframe though. Until then you may find some >>> friction with the # of assemblies and dependencies that may not seem >>> justified. >>> >>> On Wed, Nov 23, 2011 at 5:24 PM, John Duddy <[email protected]> wrote: >>> >>>> I'd like to add support for Amazon's SQS. >>>> >>>> I found a previous thread discussing this, which stated that Rhino >>>> assumed "local reliable queues". I also noticed some notes in the >>>> documentation about different instances subscribing to each other, and >>>> throwing errors if a message was sent with no subscribers (although I >>>> may have misread this). >>>> >>>> I'd like to break those assumptions, and I'd like some feedback as to >>>> if that's a Really Bad Idea (tm). >>>> >>>> First, I'd like to throw an exception if a message can't be sent by >>>> the underlying transport. It looks to me that is what already occurs >>>> if there is a failure in MSMQ (like disk full error), so I am thinking >>>> this might be OK. >>>> >>>> Second, since SQS allows queries, I'd like to move the subscription >>>> tracking responsibilities out of Rhino for SQS and have each >>>> subscription drive a query loop that will pick up messages that match >>>> the type signature. Since producers & consupers can come up and go >>>> down independently, and since SQS will store messages for 4 days, this >>>> seemed like a nice way to scale. >>>> >>>> I'm only a few days into this effort, so I'd really appreciate any >>>> tips you could offer. >>>> >>>> Thanks! >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Rhino Tools Dev" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]. >>>> For more options, visit this group at >>>> http://groups.google.com/group/rhino-tools-dev?hl=en. >>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Rhino Tools Dev" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/rhino-tools-dev?hl=en. >>> >> >> >> >> -- >> John Duddy >> [email protected] >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Rhino Tools Dev" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rhino-tools-dev?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Rhino Tools Dev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rhino-tools-dev?hl=en. > -- John Duddy [email protected] -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
