can you take a look at why this is failing with this patch? With_flat_queue_strategy.When_a_failed_message_arrives_to_error_queue_will_have_another_message_explaining_what_happened
for the life of me I can't understand that. On Mon, Jan 26, 2009 at 9:31 AM, Ayende Rahien <[email protected]> wrote: > The problem is message failures in this scenario. > > > On Mon, Jan 26, 2009 at 12:12 PM, Mike Nichols > <[email protected]>wrote: > >> >> Considering I often publicly relate my lack of insight into >> multithreading issues here is a question :) : >> Would it heavy handed (and cumbersome) to persist something about the >> message (like the id) so when it arrives and is handled it can be >> checked upon Receive to know what action to take, defaulting to a Null >> action if it has been dealt with? Are we dealing with how to >> concurrently handle the state of a message? Maybe persist a state >> object for the message before sending? >> >> On Jan 26, 9:56 am, Ayende Rahien <[email protected]> wrote: >> > That is really annoying to me, but I am not sure what we can do to >> > successfully resolve this issue. >> > >> > On Mon, Jan 26, 2009 at 11:46 AM, Ayende Rahien <[email protected]> >> wrote: >> > > It is more than that, actually, we handle some things in the peek >> directly >> > > (to support move to sub queue.I think that this is going to change, so >> we >> > > only ever deal with things in a transaction after a recieve >> > >> > > On Sun, Jan 25, 2009 at 1:23 AM, Ayende Rahien <[email protected]> >> wrote: >> > >> > >> How would you do that, and how would this help? >> > >> > >> the actual problem is that we can get into a situation where we >> process a >> > >> message on several threads on the same time. >> > >> It just happened to be the case that this is not something that we >> > >> actually do (because receive will take care of that), but it seems >> like an >> > >> aweful lot of waste to do it in this fashion. >> > >> > >> On Sun, Jan 25, 2009 at 1:20 AM, Mike Nichols < >> [email protected]>wrote: >> > >> > >>> Putting the Thread Id in the message itself to be evaluated onpeek? >> > >> > >>> On Jan 24, 11:06 pm, Ayende Rahien <[email protected]> wrote: >> > >>> > The threading model for the bus is done by spawning multiple Begin >> Peek >> > >>> > calls. >> > >>> > That is causing a problem because when a message arrives, we get >> > >>> notified >> > >>> > for the _same_ message on all threads. >> > >>> > I am not sure how to resolve this issue. >> > >>> > Any ideas? >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
errors.patch
Description: Binary data
