Skip to main content

JAXB EA3 NullPointer in Coordinator

16 replies [Last post]
scampana
Offline
Joined: 2006-01-26
Points: 0

I am using Sun's Wiseman project, which in turn uses JAXB 2.0.

Under load, I currently get a NullPointer in the Coordinator class in the method popCoordinator()...It seems that the member variable is null and then there is an attempt to access the null as an array:

table[0] = old;

Since table is null, this causes the NullPointerException.

I have been attempting to zero in on the root cause of this, however with the multiple threads it is difficult to track...

I can forsee two possibilities however which could cause this:

1. setThreadAffinity does not get called in this case OR
2. resetThreadAffinity has been called when it shouldn't have

Either way I cannot prove it..

Here is the Stack Trace for more info:

11:41:13,774 INFO [Server] JBoss (MX MicroKernel) [4.0.3SP1 (build: CVSTag=JBos
s_4_0_3_SP1 date=200510231751)] Started in 24s:762ms
11:43:38,441 INFO [STDOUT] May 2, 2006 11:43:38 AM com.sun.ws.management.server
.WSManServlet doPost
WARNING: null
java.lang.NullPointerException
at com.sun.xml.bind.v2.runtime.Coordinator.popCoordinator(Coordinator.ja
va:112)
at com.sun.xml.bind.v2.runtime.XMLSerializer.close(XMLSerializer.java:75
2)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:
272)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.jav
a:167)
at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshal
lerImpl.java:91)
at com.sun.ws.management.xml.XmlBinding.marshal(XmlBinding.java:59)
at com.sun.ws.management.addressing.Addressing.addRelatesTo(Addressing.j
ava:259)
at com.sun.ws.management.server.RequestDispatcher.(RequestDispatch
er.java:66)
at com.sun.ws.management.server.ReflectiveRequestDispatcher.(Refle
ctiveRequestDispatcher.java:64)
at com.sun.ws.management.server.WSManServlet.createDispatcher(WSManServl
et.java:147)
at com.sun.ws.management.server.WSManServlet.handle(WSManServlet.java:16
3)
at com.sun.ws.management.server.WSManServlet.doPost(WSManServlet.java:13
2)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFi
lter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrinc
ipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(Securit
yAssociationValve.java:159)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValv
e.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
ssConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo
int.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWor
kerThread.java:112)
at java.lang.Thread.run(Thread.java:595)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jtanang
Offline
Joined: 2007-10-02
Points: 0

We found the cause of our problem. It was basically due to sharing the Marshaller class, we found this in one of our framework libraries. The JAXBContext class can be reused (singleton), but the Marshaller/Unmarshaller/Validator is not thread-safe and should be recreated for each operation.

See: https://jaxb.dev.java.net/guide/Performance_and_thread_safety.html

We can reproduce the observed stacktrace (in previous posts) by simply having a JUnit testcase with multiple concurrent threads trying to marshall at the same time.

Jeff

chandra
Offline
Joined: 2003-06-12
Points: 0

We also have the same issue with 2.0.4 under high traffic. After a while, the app server cannot even print stack traces. We will be setting
-Dcom.sun.xml.bind.v2.runtime.Coordinator.debugTableNPE=true -ea

jitu
Offline
Joined: 2003-06-14
Points: 0

java with -ea flag may give a clue. Also does this happen with latest JAXB ?

frodero
Offline
Joined: 2008-01-30
Points: 0

Hi all!

I totally agree last post of jtanang, where suggests to take a look to:

https://jaxb.dev.java.net/guide/Performance_and_thread_safety.html

I also had the problem of the NullPointerException and from this moment on, ArrayIndexOutOfBounds exceptions each time I used the marshal method.

After reading some forums and the performance and thread safety reccomendations of JAXB, I modified my method (defining it as synchronized) where I invoke the marshal method and the exceptions don't appear anymore.

In addition I can say that I have not applied the modification related to the creation of a new Marshaller each time I need because I think that, for performance purposes, it's better don't do that if it is not really needed. In my case, exceptions don't appear, so I don't create a new marshaller each time.

Thank you all!!!!!

jtanang
Offline
Joined: 2007-10-02
Points: 0

We also came across this problem in one of our high-traffic site. Below is the stacktrace:

Caused by: java.lang.NullPointerException
at com.sun.xml.bind.v2.runtime.Coordinator.popCoordinator(Coordinator.java:122)
at com.sun.xml.bind.v2.runtime.XMLSerializer.close(XMLSerializer.java:823)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:310)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:230)
at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:96)
at au.com.sensis.wireless.event.logging.transform.jaxb.JaxbTransform.transformEvent(JaxbTransform.java:101)
... 76 more

We are currently using jaxb-2.1.3, and since the above occured (once so far), all subsequent attempts to marshall in the same runtime environment throws the following stacktrace:

Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at com.sun.xml.bind.v2.util.CollisionCheckStack.pushNocheck(CollisionCheckStack.java:85)
at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:465)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:301)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:230)
at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:96)
at au.com.sensis.wireless.event.logging.transform.jaxb.JaxbTransform.transformEvent(JaxbTransform.java:101)
... 76 more

I guess what we'll do also is to set "-Dcom.sun.xml.bind.v2.runtime.Coordinator.debugTableNPE=true" in our staging environment and see if we can reproduce it in performance testing. We'll post our findings.

Thanks,
Jeff

emxp
Offline
Joined: 2007-10-12
Points: 0

Hi Jeff

I encounter the same problem as yours during high traffic. I am using jaxb 2.1.4.
Do you know what causes the exception?

Thanks,

kohsuke
Offline
Joined: 2003-06-09
Points: 0

Oh, can you also enable assertions? That might find the cause, too.

Run it as "java -ea ...." to enable assertions.

scampana
Offline
Joined: 2006-01-26
Points: 0

Sure, I will grab tonight's nightly tomorrow morning and try to do it....hopefully it will give us a clue as to how it gets set to null...

Thx!

zohar_amir
Offline
Joined: 2006-06-28
Points: 0

Hi,
I have the exact same issue as you do (or at least did), did you find a solution for it?
Thanks,
Zohar

kohsuke
Offline
Joined: 2003-06-09
Points: 0

I haven't heard anything back from scampana.
Can you try my suggestion, too? use the latest bit and turn on the assertion.

guofeng
Offline
Joined: 2006-02-08
Points: 0

We met the same problem in another project these days. We use JAXB 2.1.2. Marshaller object is shared but calling to the Marshaller.marshal(Object,Node) method is synchronized.

JAXB 2.1.2 on 20070125, JDK1.5.0_03.

[code]
java.lang.NullPointerException
at com.sun.xml.bind.v2.runtime.Coordinator.popCoordinator(Coordinator.java:122)
at com.sun.xml.bind.v2.runtime.XMLSerializer.close(XMLSerializer.java:823)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:310)
at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:230)
at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:110)
.............
[/code]

Could the scheme we used cause this issue?

Thanks

kohsuke
Offline
Joined: 2003-06-09
Points: 0

Can you set "Coordinator.debugTableNPE=true;" in your application?

That should start recording who's setting the table to null in Coordinator.guyWhoSetTheTableToNull, and with that and the debugger we should be able to figure out what's going on here.

guofeng
Offline
Joined: 2006-02-08
Points: 0

I have done it on April 18 after I made that post. I read the source code and found Coordinator.guyWhoSetTheTableToNull declaration you made for this issue.

But now the isse does not occurs again.

what I did are
(1)Use JAXB 2.1.3
(2)use -Dcom.sun.xml.bind.v2.runtime.Coordinator.debugTableNPE=true to launch our application.
(3) add a print statement in Coordinator.popCoordinator() to print the stacktrace of debugTableNPE when the table field is null.

We did not change our code specially for this issue.

But it does not occurs in 7 days.

if it occurs again, i willl post the stacktrace here.

Thank.

kohsuke
Offline
Joined: 2003-06-09
Points: 0

Thanks. A bug like this is always tricky to fix....

guofeng
Offline
Joined: 2006-02-08
Points: 0

This issue never occurs again.

The application developed by this project is used to bridge a newly developped [i]client application[/i] (outsourced) to connect to a legacy application. The legacy application provide a XML interface but does not have a schema defined, so we define a schema for it. We does not have 'minOccurs="0"' defined for the optional element in the schema.

The application works well in the development environmnet, but one day we find that this issue occurs frequently when we integrate with the [i]client application[/i].

The [i]client application[/i] also use JAXB to connect to our application but uses a different schema (an excellent schema) defined by other company.

When the issue occurs, we changed the schema we defined to have 'minOccurs="0"' defined for the optional element. That is the only work we did for this issue except upgrading JAXB from 2.1.2 to 2.1.3.

Note: The issue occurred only in the side that connect to the legacy application.

Hope the above is helpful.

Thanks.

kohsuke
Offline
Joined: 2003-06-09
Points: 0

This is strange. I checked the code but I can't think of any case where the scenario you were describing could happen.

I added code to record the stack trace whenever 'table' is set to null. So you can download the next nightly, and if the same problem happens next time, can you use the debugger to check that captured stack trace?