Memory visibility would be guaranteed. If there is no happens-before ordering then one
thread's put is not always visible to another thread's get even if they happen in
the proper order. Also corruption of the table could result in a dead table.
1. Thread A -> put Kz
2. Other stuff
3. Thread B -> get Kz
(Returns cached stale value, null)
Granted there could still be some ordering problem. Like we are allowing requests to get
handled before the server is started.
Sent from my iPhone
On Dec 29, 2013, at 4:54 AM, Ales Justin
How would proper map sync help here then?
Are you saying there is a put and get going on at the same time?
Imo, this then means WF' dependencies are not done right.
btw: when do you "corrupt" a HashMap? (wrt my diff manifestation)
With multiple concurrent puts/removes, or can it be mixture of puts/gets/removes?
> On Dec 29, 2013, at 2:56, Jason Greene <jgreene(a)redhat.com> wrote:
> It looks exactly how it would manifest. Something isn't in the map that should
be, so an error is thrown.
>> On Dec 27, 2013, at 1:26 PM, Ales Justin <ales.justin(a)gmail.com> wrote:
>> That's one thing -- dunno how that did pop-up before. ;-)
>> But I doubt that just non-synchronised collections/maps cause this -- it would
>> Imo, it must also be a race-condition in WF.
>>> On 27 Dec 2013, at 17:50, Anil Saldhana <Anil.Saldhana(a)redhat.com>
>>> Stefan merged the fixes recently. I guess we need a PicketBox upgrade in WF.
>>>> On 12/27/2013 06:54 AM, Ales Justin wrote:
>>>> I often get this error:
>>>> * https://gist.github.com/alesj/8146623
>>>> I guess it's related to https://issues.jboss.org/browse/SECURITY-777
>>>> Do we have a JIRA for WF as well?
>>> wildfly-dev mailing list
>> wildfly-dev mailing list
wildfly-dev mailing list