On Tue, Jun 2, 2015 at 8:17 AM, Kevin Burton <bur...@spinn3r.com> wrote:
> On Tue, Jun 2, 2015 at 6:16 AM, Tim Bain <tb...@alumni.duke.edu> wrote: > > > Kevin, > > > > Great finds. What tool were you using? > > > > > Java Mission Control.. Free for development.. but I think the community > needs a real open source tool. Pseudo -free isn’t a good idea. > I'd heard good things but hadn't yet checked it out; guess I should. > > Is it safe to assume you'll submit patches (when you have time) so we > don't > > need to capture these in JIRA? > > > > Might want to create one. https://issues.apache.org/jira/browse/AMQ-5824 https://issues.apache.org/jira/browse/AMQ-5825 > The problem with my patch set, is that I’m still > stuck on 5.10.2. There’s a bug introduced sometime around 5.11 that only > impacts the memory store. I haven’t been able to track it down yet so I > can’t retarget my patches to head. Can you provide more details? We're using the memory store in 5.10.0, so we'd like to know what might bite us if we upgrade. > That, and I think one of my patches > doesn’t work with LevelDB so I need to fix that. > > Realistically, I should fix all those issues so that I can move between > versions. > Excellent plan. :) > > Adding a synchronized Multimap<Consumer, Subscription> to > > ManagedRegionBroker looked good to me. It won't be threadsafe against > > simultaneous registers/unregisters for the same subscription, but it > looks > > like that class already has that problem so I don't think that's a reason > > not to do it. > > > > Or store a second concurrent hash map. that would fix it. > It wouldn't; concurrent collections only protect you from corrupting the collection itself due to concurrent modifications; they don't protect you from synchronization issues between multiple collections like you'd have here (since you'll want to always have an element in neither collection or in both, but without explicit locking you could have it in one but not the other) and they don't protect you from synchronization issues where you observe the current state of the collection and act upon it (where it might have changed between your observation and your action). I've generally found that concurrent collections hurt more than they help, mainly because developers assume they're magically safe in multithreaded applications when they're not. Guess maybe I should just switch to Scala so I don't have to worry about any of that... > In addConsumerToList(), I think we can do a sorted insertion (iterate > > through the list till you find the right place based on the comparator, > > then insert) to skip the re-sort. Either we'll be rolling the list or we > > won't, but either way the list will be in sorted order, except that the > > minimum element might not be the first one. So find the minimum > element's > > index (O(log N), but can be optimized to O(1) for the not-rolling case), > > then do a sorted insert starting at that index and wrapping if necessary. > > > True.. That would definitely make that faster. > > 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> >
