On Wed, Jan 14, 2015 at 2:44 PM, Endre Varga <endre.va...@typesafe.com> wrote:
> > > On Fri, Jan 9, 2015 at 10:02 PM, Viktor Klang <viktor.kl...@gmail.com> > wrote: > >> >> >> On Fri, Jan 9, 2015 at 9:40 PM, David Hotham <david.hot...@googlemail.com >> > wrote: >> >>> Of course it's normal and expected that a PriorityQueue returns equal >>> priority elements in arbitrary order. That's just how heaps work. However >>> that doesn't imply that a mailbox has to do the same thing! >>> >> >> Absolutely, the reordering is not a requirement :) However, silently >> switching to a new, non-reordering-of-same-priority implementation would >> risk breaking existing code (that for some reason relies on this behavior). >> > > I disagree, previously the order between same priority entries was > undefined, and undefined includes that the order is unchanged (the new > behavior). Just my 2c. > The proposed solution has worse performance than the current though. That would be a regression. > > -Endre > > >> >> >>> >>> For instance, I guess that it shouldn't be very hard for the mailbox to >>> maintain a sequence number that it associates with each message. >>> >> >> Sure! The question is how how big the impact is on memory consumption and >> performance. >> >> >>> Then it could order messages first according to the comparator that it >>> currently uses, and second according to the sequence number. That way it >>> would return equal priority messages in the same order that it saw them >>> arrive - which gives exactly the property that I'd hoped for. >>> >> >> Absolutely :) >> >> >>> >>> I can't tell from your reply whether you think that maintaining order >>> for equal priority messages is desirable or not. >>> >> >> I think it could be interesting as an alternative to the current version >> of the PriorityMailbox, or perhaps even as a replacement if it is >> performing as well as the thing it replaces. >> >> >>> >>> - If yes, what do you think about an implementation along these >>> lines? Is it worth me raising an issue at github? >>> >>> I wish I had time to do that, is it something you'd be willing/able to >> take a stab at? Would love to see something like that. >> >>> >>> - If no, can I at least encourage the Akka maintainers to add an >>> explicit note to the documentation, so that other users are less likely >>> to >>> fall into my error? >>> >>> I think this should be done anyway, since it as you said, and I >> confirmed, surprising at first. :) >> >> >> >>> Cheers, >>> >>> David >>> >>> On Friday, 9 January 2015 19:43:27 UTC, √ wrote: >>>> >>>> Hi David, >>>> >>>> yes, I can definitely understand that it can be surprising, but I >>>> wouldn't call it a bug -per se-, since it is not a promise that was >>>> violated. >>>> >>>> If you happen to have, or come by, a performant version of a >>>> PriorityQueue with the semantics you described, please don't hesitate to >>>> share it. >>>> >>>> On Fri, Jan 9, 2015 at 7:21 PM, David Hotham <david....@googlemail.com> >>>> wrote: >>>> >>>>> It occurs to me that I wasn't completely clear: >>>>> >>>>> - Of course the priority mailbox must break message ordering in >>>>> some general sense. Else it wouldn't be a priority mailbox at all! >>>>> - But it is highly surprising to me that it should break ordering >>>>> for messages of equal priority between a sender-receiver pair. >>>>> >>>>> >>>>> On Friday, 9 January 2015 17:58:40 UTC, David Hotham wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> We've been tracking down a bug in which reading from a TCP stream was >>>>>> getting all messed up. >>>>>> >>>>>> It turns out that we see the problem only when our actor handling >>>>>> Tcp.Received messages is using an UnboundedPriorityMailbox; the default >>>>>> mailbox doesn't exhibit any problem. >>>>>> >>>>>> I believe that the issue is that the UnboundedPriorityMailbox is >>>>>> backed by a PriorityBlockingQueue; and that, per the documentation for >>>>>> that >>>>>> class, "Operations on this class make no guarantees about the ordering of >>>>>> elements with equal priority". >>>>>> >>>>>> That is, it seems that the UnboundedPriorityMailbox breaks the >>>>>> guarantee of message ordering per sender–receiver pair. In our case, the >>>>>> result being that different chunks of the TCP data stream arrive not in >>>>>> the >>>>>> order in which they were read from the wire. >>>>>> >>>>>> Does this analysis seem to be correct? >>>>>> >>>>>> If yes, is it a bug? Would you like me to raise a ticket? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> David >>>>>> >>>>> -- >>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/ >>>>> current/additional/faq.html >>>>> >>>>>>>>>> Search the archives: https://groups.google.com/ >>>>> group/akka-user >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Akka User List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to akka-user+...@googlegroups.com. >>>>> To post to this group, send email to akka...@googlegroups.com. >>>>> Visit this group at http://groups.google.com/group/akka-user. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> √ >>>> >>> -- >>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>> >>>>>>>>>> Check the FAQ: >>> http://doc.akka.io/docs/akka/current/additional/faq.html >>> >>>>>>>>>> Search the archives: >>> https://groups.google.com/group/akka-user >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Akka User List" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to akka-user+unsubscr...@googlegroups.com. >>> To post to this group, send email to akka-user@googlegroups.com. >>> Visit this group at http://groups.google.com/group/akka-user. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Cheers, >> √ >> >> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> --- >> You received this message because you are subscribed to the Google Groups >> "Akka User List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to akka-user+unsubscr...@googlegroups.com. >> To post to this group, send email to akka-user@googlegroups.com. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to akka-user+unsubscr...@googlegroups.com. > To post to this group, send email to akka-user@googlegroups.com. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Cheers, √ -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
