I am seeing an additional message in the queue that is dated...did you add some kind of timestamping message?
On Jan 26, 1:11 pm, Ayende Rahien <[email protected]> wrote: > 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? > > > > errors.patch > 10KViewDownload --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
