| Summary: | JacORBConfiguration's getAttributeXXX methods are not thread safe | ||
|---|---|---|---|
| Product: | JacORB | Reporter: | franky.bugzilla |
| Component: | ORB | Assignee: | Mailinglist to track bugs <jacorb-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | jacorb |
| Priority: | P5 | ||
| Version: | 3.5 | ||
| Hardware: | PC | ||
| OS: | Windows NT | ||
| Attachments: | thread dump | ||
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 Do you have a thread dump? Hopefully fixed by SHA 6570aa2109ac3506c14fd928358107a66a5b7d23 |
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.