activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Burton <bur...@spinn3r.com>
Subject Re: More ActiveMQ hotspots.. courtesy of continuous profiling :)
Date Wed, 03 Jun 2015 17:16:17 GMT
Thanks for creating the issues!


> > 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.
>
>
Advisories break when using the memory store. A warning that a null pointer
exception was caught goes to the log but the advisories aren’t raised.

I tried to git bisect it but wasn’t able to duplicate it easily. I think
because of some git idiosyncrasy prevented me from finding the commit that
broke.


> 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 had thought about that.  I assumed that the multi map was implemented as
two concurrent maps.  If each operation is concurrent and atomic then I’m
fine with that solution.

I think all we need is that the method() is atomic, not the underlying
data.  Maybe I’m wrong though.  Perhaps there’s a race where we can try to
remove something while it’s being added?


> 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...
>
>
Perhaps.. but a lot of these things are called out in the documentation.

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>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message