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].
For more options, visit this group at
http://groups.google.com/group/rhino-tools-dev?hl=en.
