The message is actually a date time that I am sending. The crazy part is that I can't figure out what the hell is going on there because I am getting AppSpecific is not there!
On Mon, Jan 26, 2009 at 12:32 PM, Mike Nichols <[email protected]>wrote: > > wait...i see > > 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 -~----------~----~----~----~------~----~------~--~---
