Thread safety issue with FI

Question

Thread safety issue with FI

Tomas-Kraus opened this issue 15 years ago · comments

A CXF user is running into a thread safety issue when using FI. It MAY
actually be a JDK bug though. You can see the full stack trace at:
https://issues.apache.org/jira/secure/attachment/12424481/FullStackTrace.log
but the gist is that there are SEVERAL threads like:

java.lang.Thread.State: RUNNABLE
at java.lang.String.intern(Native Method)
at
com.sun.xml.fastinfoset.util.NamespaceContextImplementation.getNamespaceURI(Nam
at
org.apache.cxf.interceptor.WrappedOutInterceptor.handleMessage(WrappedOutInterc

Basically, stuck in String.intern called from
NamespaceContextImplementation.getNamespaceURI

Environment

Operating System: All
Platform: All
URL: https://issues.apache.org/jira/browse/CXF-2530

Affected Versions

[current]

Tomáš Kraus · Answer 1 · Thu Sep 13 2018 21:07:29 GMT+0800 (China Standard Time)

Issue Imported From: https://github.com/javaee/metro-fi/issues/28
Original Issue Raised By:@glassfishrobot
Original Issue Assigned To: @glassfishrobot
Original Issue Closed By:@glassfishrobot

Tomáš Kraus · Answer 2 · Tue Nov 10 2009 19:34:58 GMT+0800 (China Standard Time)

@glassfishrobot Commented
Reported by dkulp

Tomáš Kraus · Answer 3 · Tue Nov 10 2009 21:12:57 GMT+0800 (China Standard Time)

@glassfishrobot Commented
oleksiys said:
can you pls. elaborate, how stacktrace is related to FI thread safety?
I see just one thread blocked inside String.intern(), does it mean this thread is blocked forever?
Which JDK, OS are you using?

I'll change priority to P3.

Tomáš Kraus · Answer 4 · Tue Nov 10 2009 21:20:20 GMT+0800 (China Standard Time)

@glassfishrobot Commented
dkulp said:
Linux x86
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)
Jboss 5.1.0.GA

Eventually, tomcat stops responding to requests due to all the "service
threads" from the http stack being stuck. The kill -3 results in all the
threads with that same stack trace. Most are marked RUNNABLE, but they are all
stuck there.

Like I said, this MAY be some sort of JVM bug, not an FI bug. Not really
sure. That said, I'm providing changes in CXF to work around it so dropping to
P3 is fine.

Tomáš Kraus · Answer 5 · Tue Nov 10 2009 21:33:16 GMT+0800 (China Standard Time)

@glassfishrobot Commented
oleksiys said:
thanks for the info.
I'll let JDK team to investigate the issue.

Tomáš Kraus · Answer 6 · Wed Nov 11 2009 13:31:39 GMT+0800 (China Standard Time)

@glassfishrobot Commented
oleksiys said:
I'm trying to create JDK issue and need more info.

Full OS version (uname -a)
Was the problem reproducible with "-Xint" flag
Was the problem reproducible with "-server" flag
Frequency: How often does the bug occur?

BTW, were you able to reproduce the issue with older JDK6 version?

Thanks in advance.

Tomáš Kraus · Answer 7 · Wed Nov 11 2009 14:27:59 GMT+0800 (China Standard Time)

@glassfishrobot Commented
oleksiys said:
looks like FI consumes all perm gen memory, which causes the issue.
I've updated the code to not use String.intern().

Can you pls. try this FI bundle?
https://fi.dev.java.net/files/documents/2634/145215/FastInfoset.jar

Tomáš Kraus · Answer 8 · Wed Nov 11 2009 15:49:12 GMT+0800 (China Standard Time)

@glassfishrobot Commented
oleksiys said:
Paul Sandoz proposed simple test to see if there is permgen memory leak with String.interns
Bellow is the simple code to run, which checks if permgen memory gets cleaned by GC, when there are
no alive references to an interned String.

My output is:
(1) 193026137
(2) 193026137
(3) 1627433763
(4) 1627433763

which is correct. (1) == (2) && (3) == (4) && (1) != (3)

Will appreciate if reporter will be able to run this test and provide the result.

Thanks.

public static void main(String[] args) throws InterruptedException

{ StringBuffer sb = new StringBuffer(); sb.append('a'); sb.append('a'); sb.append('a'); sb.append('a'); System.out.println("(1) " + System.identityHashCode(sb.toString().intern())); System.out.println("(2) " + System.identityHashCode(sb.toString().intern())); System.gc(); Thread.currentThread().sleep(1000); System.gc(); System.out.println("(3) " + System.identityHashCode(sb.toString().intern())); System.out.println("(4) " + System.identityHashCode(sb.toString().intern())); }

Tomáš Kraus · Answer 9 · Wed Nov 11 2009 18:46:43 GMT+0800 (China Standard Time)

@glassfishrobot Commented
dkulp said:
I think I figured out what is happening in CXF to cause this and it's a bug in
CXF. The problem is that writer.getNamespaceContext().getNamespaceURI(pfx)
with FI is returning "" if the prefix is not declared. That is proper per
spec. However, the other implementations we test with (woodstox, jdk6 built
in stax) return null (probably a bug in those implementations). In SOME
places, the code in CXF was just checking for null and thus was causing a loop
causing a ton of String.interns and such.

Sorry for the confusion.

Tomáš Kraus · Answer 10 · Thu Nov 12 2009 10:52:30 GMT+0800 (China Standard Time)

@glassfishrobot Commented
oleksiys said:
thank you for info.
I'll remove String.intern() in that particular place (NamespaceContextImplementation.getNamespaceURI()),
because it wasn't controlled by FastInfosetParser.get/setInterning(...) settings.

Tomáš Kraus · Answer 11 · Thu Nov 12 2009 18:17:43 GMT+0800 (China Standard Time)

@glassfishrobot Commented
dkulp said:
Just an extra follow up...

The CXF user has confirmed that the new jar mentioned above also fixes the
issue for them using the existing CXF code base. Thanks for the fix!

Tomáš Kraus · Answer 12 · Tue Nov 10 2009 19:34:58 GMT+0800 (China Standard Time)

@glassfishrobot Commented
Was assigned to fi-issues

Tomáš Kraus · Answer 13 · Mon Apr 24 2017 15:26:12 GMT+0800 (China Standard Time)

@glassfishrobot Commented
This issue was imported from java.net JIRA FI-28

Tomáš Kraus · Answer 14 · Thu Nov 12 2009 18:17:43 GMT+0800 (China Standard Time)

@glassfishrobot Commented
Marked as fixed on Thursday, November 12th 2009, 2:17:43 am