Huh. I haven’t seen CHM perform poorly in that regard but I’m open minded. I might post to the mechanical-sympathy list about that as there is a lot of focused discussion on that front.
Ten years. wow. Crazy. I think if it turns out that updateMessage is NEVER used then I can just used a concurrent priority queue and make updateMessage throw a RuntimeException( “not implement” ) since it’s only ever used to meet the interface and not used to actually do any work. This would dramatically lower memory. I’m also curious what PriorityBlockingQueue looks like in terms of memory consumption vs CHM. I think we’re going to be stuck on using an in memory ActiveMQ for a while. Would be nice to have replication but I don’t think it’s going to be possible - at least for the short term. On Wed, Apr 1, 2015 at 1:24 PM, Rob Davies <rajdav...@gmail.com> wrote: > Its historical - probably at least 10 years old in origin. Only warning I > would give is that ConcurrentHashMap can be slow and a memory hog for lots > of inserts deletes - synchronisation around a HashMap may perform better - > would be worth validating that though > > > > > On 1 Apr 2015, at 20:57, Kevin Burton <bur...@spinn3r.com> wrote: > > > > I’m curious why MemoryMessageStore is backed by a LinkedHashMap and not a > > queue data structure. > > > > Does anyone know? It might be just do to the age. > > > > The one thing that could break it is: > > > > public void updateMessage(Message message) > > > > .. which updates the message by ID. But make we could keep two indexes, > a > > queue and a concurrent map. but I think updateMessage is only called for > > persistent messages. > > > > I’m asking because I’m investigating implementing JMS priority in the > > memory store. If it was backed by a priority queue (lower case, not > > necessarily proposing the PriorityQueue but more of > > java.util.concurrent.PriorityBlockingQueue or maybe even something from > > disruptor.) > > > > It would be trivial to implement JMS priority at that point I think. > > Messages would just be returned based on their JMS priority then FIFO > order. > > > > Also, this class uses a lot of synchronization which would be removed if > it > > was refactored this way. > > > > I’m still experimenting with this idea. I still have to fix the 5.11.x > > regressions we’ve found. > > > > thoughts? > > > > Kevin > > > > -- > > > > Founder/CEO Spinn3r.com > > Location: *San Francisco, CA* > > blog: http://burtonator.wordpress.com > > … or check out my Google+ profile > > <https://plus.google.com/102718274791889610666/posts> > > <http://spinn3r.com> > -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile <https://plus.google.com/102718274791889610666/posts> <http://spinn3r.com>
