Thread safety issue with FI

[Tomas-Kraus]

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]

[Tomas-Kraus]

• 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

[Tomas-Kraus]

@glassfishrobot Commented Reported by dkulp

[Tomas-Kraus]

@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.

[Tomas-Kraus]

@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.

[Tomas-Kraus]

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

[Tomas-Kraus]

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

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

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

Thanks in advance.

[Tomas-Kraus]

@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

[Tomas-Kraus]

@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())); }

[Tomas-Kraus]

@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.

[Tomas-Kraus]

@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.

[Tomas-Kraus]

@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!

[Tomas-Kraus]

@glassfishrobot Commented Was assigned to fi-issues

[Tomas-Kraus]

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

[Tomas-Kraus]

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