[ http://jira.jboss.com/jira/browse/JBMQ-63?page=comments#action_12313195 ] Adrian Brock commented on JBMQ-63: ----------------------------------
Logged In: YES user_id=9459 I am willing to be proved wrong by experiment, but an ArrayList is more efficient for this use case (in fact in most use cases). 1) It requires no additional object contructions, except the array object when resizing (linked lists have internal node objects containing the "next" pointer) 2) It can be efficiently iterated with a for(i in list) list.get(i); whereas a LinkedList requires contructing an iterator object on every request Since the List will be pretty much constant size, the only advantage a LinkedList has is that removal on an already located element is quicker. It is probably worth creating an interface for the receiver operations and let people plugin the implementation that best fits their use case. > Wrong behaviour with multiple listeners to a queue > -------------------------------------------------- > > Key: JBMQ-63 > URL: http://jira.jboss.com/jira/browse/JBMQ-63 > Project: JBoss MQ > Type: Feature Request > Reporter: SourceForge User > Assignee: Adrian Brock > > > SourceForge Submitter: sverkera . > I wanted to have messages distibruted to multiple > listeners from one queue but no matter how many > listeners I added, it was always the first and > occationally the second that were given all the > messages. I asked in the forum in thread > http://www.jboss.org/thread.jsp? > forum=48&thread=36553 about this and eventually I > found out the answer. > The answer is to replace > "HashSet receivers = new HashSet();" > in org.jboss.mq.server.BasicQueue with > "LinkedList receivers = new LinkedList();" > Changing to LinkedList gave the expected behaviour, > messages are now distributed evenly to all listeners. The > reason for that is explained in the text below which I've > copied from the thread. I've been running the server > with this patch for a couple of months now and it works > excellent. > (Below is text copied from the thread) > BasicQueue keeps the waiting receivers in a HashSet > and when it gets a messag, it calls the > internalAddMessage method which iterates through the > receivers and picks the first subscription that matches > the headers of the message and pass the message on > to it's ClientConsumer instance. After that it removes > that subscription from the receivers. The > ClientConsumer passes the message on through the > registered ClientIL to a Connection's asyncDeliver > method. It is then passed on to a SpyConsumer > instance with the addMessage method. In my case that > is a SpyMessageConsumer which puts the message in a > LinkedList. A thread then picks it from the LinkedList and > call the onMessage method on my listener. > I haven't found out exactly how yet but when the > ClientConsumer has delivered the message it's > subscription is added again to the receivers in > BasicQueue. > receivers is a HashSet instance and it's implementation > uses a HashMap to store it's entries in the HashMap > key. HashMap keys are stored in an array and when a > new key/value pair (the value is null in this case) is > added, the array is searched for the first empty position > in the array, which happens to be the first position since > that is the one where the key were removed by the > iterator in BasicQueue.internalAddMessage. > This means that the order of the subscriptions is > maintained more or less to be the same as when they > were registered the first time. internalAddMessage picks > the first subscription and the only time it will pick the > second subscription is when it receives a message > before the first subscription has finished processing the > previous message. ClientConsumer uses a thread pool so > it looks like that the thread that calls it from BasicQueue > just drops it of on a thread from the pool and returns so > most of the times the first subscription process the > messages as fast as they arrive so it's only in a few > cases the second subscriber get used. > That means that most of the messages ends up in the > LinkedList of the SpyMessageConsumer to which my first > listeners is registered. The second listener receives a > few and the rest of them receives nothing.. > The behaviour I expected was that the messages would > be evenly between the listeners, I think that is logica. > That behaviour should be acomplished by changing the > receivers in BasicQueue from a HashSet to a LinkedList, > then the subscriber that has finished is added to the > end of the list and have to wait until last. I'll test that > and see what happens. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
