Read only archive ; use https://github.com/JacORB/JacORB/issues for new issues
Bug 991 - JacORBConfiguration's getAttributeXXX methods are not thread safe
Summary: JacORBConfiguration's getAttributeXXX methods are not thread safe
Status: RESOLVED FIXED
Alias: None
Product: JacORB
Classification: Unclassified
Component: ORB (show other bugs)
Version: 3.5
Hardware: PC Windows NT
: P5 critical
Assignee: Mailinglist to track bugs
URL:
Depends on:
Blocks:
 
Reported: 2014-09-08 03:51 UTC by franky.bugzilla
Modified: 2014-11-07 05:05 UTC (History)
1 user (show)

See Also:


Attachments
thread dump (1.11 KB, text/plain)
2014-09-08 03:51 UTC, franky.bugzilla
Details

Note You need to log in before you can comment on or make changes to this bug.
Description franky.bugzilla 2014-09-08 03:51:27 UTC
Created attachment 445 [details]
thread dump

I have a setup where I connect to multiple CORBA enabled devices in parallel from a thread pool. Once in a while I see that a number of threads used for the CORBA communication are stuck in an endless loop (threads are running at 100%) at start up of my application. A thread dump of a stuck thread can be found in the attached file. The threads got stuck in HashMap.getEntry which is known behavior when accessed and modified concurrently and the owner of this HashMap is JacOrbConfiguration. In fact there are 3 HashMaps which can be accessed concurrently in JacOrbConfiguration being stringAttributes, booleanAttributes and numberAttributes. The problem is that some of the methods getAttribute, getAttributeAsBoolean, getAttributeAsInteger try to get the value from the HashMap and if not the default value is put into the HashMap. If those getAttributeXXX methods are called concurrently the HashMaps can be accessed and modified concurrently and result in an infinite loop. I encountered this on 3.3 but I guess it's also on 3.5 as I didn't find any bug report related to this.
Comment 1 franky.bugzilla 2014-10-01 08:47:36 UTC
I've encountered this problem on 3.3 but I see the JacORBConfiguration code in 3.5 is the same in this area, meaning the problem is also present in 3.5
Comment 2 Nick Cross 2014-10-02 03:59:45 UTC
Do you have a thread dump?
Comment 3 Nick Cross 2014-11-07 05:05:56 UTC
Hopefully fixed by SHA 6570aa2109ac3506c14fd928358107a66a5b7d23