My suggestion: put a breakpoint when you can find a consumer for the saga and then try to see why you aren't getting it
On Fri, May 28, 2010 at 4:05 PM, Jan Limpens <[email protected]> wrote: > Well, it's working sometimes - and I am getting no complaints from Windsor. > Also the Saga has no direct dependencies, here I am resolving my services > via ServiceLocator (I persist it using NHibernate, so I the saga does not > come from a Windsor aware place). But in the cases where it does not work, > it never comes to using the locator at all. It (whatever this is) dies a > quiet death before that. And then it works again and then it does not. > > > > On Fri, May 28, 2010 at 4:47 AM, Ayende Rahien <[email protected]> wrote: > >> Hm, >> There shouldn't be any scenario where StartSagaOrder (InitiateBy) doesn't >> work. >> Unless... we use Windsor, and that won't give us any component that cannot >> be resolved. >> Is there a dependency there that is missing? >> >> >> On Fri, May 28, 2010 at 4:31 AM, Jan Limpens <[email protected]>wrote: >> >>> No, the Saga is persisted by NHibernate and seemingly well. It loads its >>> State with a left join and this part is working nicely so far. >>> >>> What I get are completely random >>> >>> 2010-05-27 22:17:19,204 [Rhino Service Bus Worker Thread #0] ERROR >>> Rhino.ServiceBus.Impl.DefaultServiceBus - Got message >>> Limpens.Messages.SalesOrders.OrderSaga.Commands.StartOrderSaga, but had no >>> consumers for it >>> >>> exceptions for all different types of messages. This is sometimes so, >>> some other times I can send my messages and they a re received, get passed >>> to the nicely initialized Saga and so on. It changes from one minute to the >>> other. I suspected that the problem could be with the web application >>> hosting a DefaultHost and tried it out with Rhino.ServiceBus.Host.exe, but >>> get the exact same result (-ing irregularities). >>> >>> I have this on two different machines, (win7 32 and 64), so it probably >>> is not physics related. I am a bit unsure on how one could proceed. >>> >>> That's how I start it up: >>> >>> $clientName = "SomeClientName" >>> $srvName = "SalesOrders Service " + $clientName >>> .\Rhino.ServiceBus.Host.exe ` >>> /Action:"Debug" ` >>> /Name:$srvName ` >>> /BootStrapper:"Limpens.SalesOrders.Services.SalesOrdersServiceBootStrapper, >>> Limpens.SalesOrders.Services" ` >>> /ConfigFile:"Limpens.SalesOrders.Services.dll.config" ` >>> /Host:"Rhino.ServiceBus.Hosting.DefaultHost, Rhino.ServiceBus" ` >>> /Assembly:"Limpens.SalesOrders.Services.dll" >>> >>> My config is like that: >>> >>> <?xml version="1.0" encoding="utf-8" ?> >>> <configuration> >>> <configSections> >>> <section name="castle" >>> >>> type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, >>> Castle.Windsor" /> >>> </configSections> >>> <castle> >>> <facilities> >>> <facility id="rhino.esb" > >>> <bus threadCount="1" >>> numberOfRetries="5" >>> endpoint="msmq://localhost/SomeClientName" >>> /> >>> <messages> >>> <add name="Limpens.Messages.SalesOrders" >>> endpoint="msmq://localhost/SomeClientName"/> >>> <add name="Limpens.Messages.Inventory" >>> endpoint="msmq://localhost/SomeClientName"/> >>> <add name="Limpens.Messages.SalesOrders.OrderSaga.Commands" >>> endpoint="msmq://localhost/SomeClientName"/> >>> <add name="Limpens.Messages.SalesOrders.OrderSaga.Events" >>> endpoint="msmq://localhost/SomeClientName"/> >>> </messages> >>> </facility> >>> </facilities> >>> </castle> >>> </configuration> >>> >>> I added so many message namespaces, because I was under the impression >>> this was necessary to work (by reading the code it should not be). But I >>> could not start a single Saga - once I put the concrete saga message >>> namespaces in there, and then it worked a few times. Wtf! >>> >>> Well, help would be greatly appreciated... >>> >>> -- >>> Jan >>> >>> >>> On Thu, May 27, 2010 at 6:00 PM, Mike Nichols >>> <[email protected]>wrote: >>> >>>> What about your saga persistence provider? Is it dropping your state? >>>> Transient? Just a wild guess. >>>> >>>> >>>> On Thu, May 27, 2010 at 1:14 PM, Jan Limpens <[email protected]>wrote: >>>> >>>>> No, it must be something else. I suspect the way I setup the host. It >>>>> seems that the host sometimes is "there" and sometimes not. I need to >>>>> debug >>>>> this deeper... >>>>> >>>>> >>>>> On Wed, May 26, 2010 at 5:40 PM, Mike Nichols < >>>>> [email protected]> wrote: >>>>> >>>>>> This should work...I do this currently. Are you sure you aren't >>>>>> completing the saga in your 'CancelOrder' handler? >>>>>> >>>>>> On Wed, May 26, 2010 at 12:47 PM, Jan Limpens >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I posted this on stackoverflow as well... >>>>>>> >>>>>>> http://stackoverflow.com/questions/2916213/rhine-servicebus-sagas-with-multiple-messages >>>>>>> >>>>>>> I have a saga that can handle multiple messages like so: >>>>>>> >>>>>>> public class OrderSaga : ISaga<Order> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> , InitiatedBy<StartOrderSaga> >>>>>>> >>>>>>> , Orchestrates<CancelOrder> >>>>>>> , Orchestrates<PaymentForOrderReceived> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> , Orchestrates<CheckOrderWasPaid> >>>>>>> >>>>>>> , Orchestrates<OrderAbandoned> >>>>>>> >>>>>>> , Orchestrates<CheckOrderHasBeenShipped> >>>>>>> >>>>>>> , Orchestrates<OrderShipped> >>>>>>> >>>>>>> , Orchestrates<CheckOrderHasDelayDuringShipment> >>>>>>> >>>>>>> , Orchestrates<OrderArrivedAtDestination> >>>>>>> >>>>>>> , Orchestrates<OrderCompleted> >>>>>>> >>>>>>> {...} >>>>>>> >>>>>>> but only Orchestrates<CancelOrder>, the first, seems to be picked up. >>>>>>> So I suppose (I did not find the line, but am under a strong impression >>>>>>> this >>>>>>> is so), that only the first Orchestrates is registered. >>>>>>> >>>>>>> Probably this is by design. From what I imagined a saga to be, it >>>>>>> seems only logical that it receives many different messages, but I >>>>>>> might be >>>>>>> wrong. I might be wrong with my whole assumption, too :) >>>>>>> >>>>>>> How am I supposed to handle this? Are Sagas supposed to only handle >>>>>>> one (in my case) a ChangeStateMessage or should I wire the other >>>>>>> ConsumerOfs/Orchestrates by hand? >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jan >>>>>>> >>>>>>> -- >>>>>>> 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]<rhino-tools-dev%[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]<rhino-tools-dev%[email protected]> >>>>>> . >>>>>> For more options, visit this group at >>>>>> http://groups.google.com/group/rhino-tools-dev?hl=en. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Jan >>>>> >>>>> -- >>>>> 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]<rhino-tools-dev%[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]<rhino-tools-dev%[email protected]> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/rhino-tools-dev?hl=en. >>>> >>> >>> >>> >>> -- >>> Jan >>> >>> -- >>> 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]<rhino-tools-dev%[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]<rhino-tools-dev%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/rhino-tools-dev?hl=en. >> > > > > -- > Jan > > -- > 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]<rhino-tools-dev%[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.
