Can you run the host in debug mode /Debug and then attach the debugger to it then send a message to the endpoint?
On Fri, May 28, 2010 at 11:25 AM, Jan Limpens <[email protected]> wrote: > That's the problem, I cannot. The module is not loaded for debugging for > whatever reason. That's why I included the code beyond. Is it possible that > the host is 'running wrong' or not at all? > > > On Fri, May 28, 2010 at 1:52 PM, Ayende Rahien <[email protected]> wrote: > >> Put a breakpoint in the line logging the problem, see what it does. >> >> >> On Fri, May 28, 2010 at 6:08 PM, Jan Limpens <[email protected]>wrote: >> >>> Well, I tried to step into DefaultServiceBus.Transport_OnMessageArrived, >>> but got an empty red circle, Rhino.ServiceBus is not loaded as a module >>> during debugging. So maybe I make a very stupid mistake somewhere... >>> I get the same messages, when there is no external service running, so >>> the problem seems to be, not that the saga is not found, but that the host >>> isn't. >>> Further hints: I get 'better' results (saga found), when the debugger is >>> attached, but I get the same message about the consumer of a sagamessage not >>> being found, even when hitting an active breakpoint within the saga. >>> >>> This is weird shit! >>> >>> Let's see >>> >>> In Global.asax.cs >>> >>> private DefaultHost _salesOrdersHost; >>> >>> // runs and exits nicely >>> private void RegisterAndStartMessageBusHost(IWindsorContainer container) >>> { >>> container.Register( >>> Component >>> .For<IMessageModule>() >>> .ImplementedBy<UnitOfWorkMessageModule>() >>> ); >>> >>> var endpoint = Settings.Default.MessageQueueEndpoint; >>> >>> PrepareQueues.Prepare(endpoint, QueueType.Standard); >>> _salesOrdersHost = new DefaultHost(); >>> _salesOrdersHost.BusConfiguration(c => c.Bus(endpoint) >>> .Receive(typeof(StartOrderSaga).Namespace, endpoint) >>> .Receive(typeof(OrderCreated).Namespace, >>> endpoint) >>> .Receive(typeof(SalesOrdersNamespaceProvider).Namespace, >>> endpoint) >>> .Threads(1)); >>> _salesOrdersHost.Start<SalesOrdersServiceBootStrapper>(); >>> } >>> >>> and the boot strapper looks like this: >>> >>> public class SalesOrdersServiceBootStrapper >>> : AbstractBootStrapper >>> { >>> protected override void ConfigureContainer() >>> { >>> base.ConfigureContainer(); >>> container.AddFacility("logging", new >>> LoggingFacility(LoggerImplementation.Log4net)); >>> >>> container.Register( >>> Component >>> .For<IMessageModule>() >>> .ImplementedBy<UnitOfWorkMessageModule>() >>> ); >>> >>> container.Kernel.Resolver >>> .AddSubResolver(new QueryableResolver(container.Kernel)); >>> >>> container >>> .Register(Component >>> .For(typeof(IDao<,>)) >>> .ImplementedBy(typeof(DomainDao<,>)) >>> ); >>> >>> container.Register( >>> Component >>> .For(typeof(ISagaPersister<>)) >>> .ImplementedBy(typeof(NHibernateSagaPersister<>)) >>> ); >>> >>> var windsorServiceLocator = new >>> WindsorServiceLocator(container); >>> ServiceLocator.SetLocatorProvider(() => >>> windsorServiceLocator); >>> DomainEvents.EventContainer = new >>> ServiceBusEventResolver(container.Kernel); >>> } >>> >>> Looks not suspicious to me... >>> >>> both starbucks.exe and the nservicebus pubsub example run happily on my >>> system. >>> >>> >>> On Fri, May 28, 2010 at 10:29 AM, Ayende Rahien <[email protected]>wrote: >>> >>>> 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]<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.
