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

Reply via email to