We are using the XML wrapper to retrieve data from the mainframe. We get an intermittent error (about 4 times a month) which we are unable to reproduce in our test environment…
Unfortunately the error code is not documented in the developers toolkit.
XML Runtime Exception 2000 0005 Internal Error: Java Exception. java.lang.NullPointerException
excerpt from the stack trace:
com.softwareag.entirex.xml.rt.cy.a(Unknown Source)
com.softwareag.entirex.xml.rt.XMLRPCService.invokeXML(Unknown Source)
com.softwareag.entirex.xml.rt.XMLRPCService.invokeXML(Unknown Source)
com.vrs.dataservices.dataaccessors.DataAccessorNatRPC.getDataFromRIMS(Unknown Source)
The DataAccessorNatRPC.getDataFromRIMS method executes the invokeXML (String xmldocument) method of a XMLRPCService object.
We are using xmm files for the XML mappings.

I have attached examples of the IDL and XMM files. The problem has occurred with 4 different types of data access, so it is not specific to any one XMM / IDL file. Each of trhem uses the DataAccessorNatRPC as a base class.

Has anyone seen this error before?

Java 1.4.2
EntireX 7.2.1
Natural 4.1.4 (z/OS)

Thanks

Raymond
nullpointer.zip (7.2 KB)

The message in the 7.2.1 Messages and Codes says:
20000005 Internal Error: Java Exception
Explanation Internal error.
Action Contact support.

Which is what I was going to suggest anyways: when you have errors like this, support is the best place to call for help!

Hi Raymond,

I agree with Douglas. But nethertheless I had a quick look to your Java sources.

This can be a problem with your pool implementation. You need to be aware that the XMLRPCService class is not thread-safe. However, multiple parallel threads might run on the same instance because aquireService() returns a singleton instance of XMLRPCService for the same XMM file. And this might result in any kind of desaster in the XML Runtime

You should check if that situation is possible in your application (multiple parallel threads working on the same XMLRPCService object). If yes you need to revise your code. You should also be aware that the Broker class is thread-safe, however parallel calls will be serialized so this is not recommended due to performance issues.

For an efficient pooling I would recommend using a Stack. aquireService() should pop() an entry from the stack (or create a new one if the stack is empty) and return this entry to the caller. The caller needs to put back the object when work is done with push(). Conceptually you would have this data structure:

Hashtable: XMM_filename → [Stack of XMLRPCService]

And whenever you create a new instance of XMLRPCService also use a fresh instance of Broker.

BTW please make sure that you are using the latest hotfix for the entirex.jar classes …

Hope this helps.

Rolf

I think you may have hit the nail on the head. This code represents the data layer to a web application, so it is very possible that the problem is thread related…

I will relook at making the implementation thread-safe and if the problem continues I will follow up with SAG support.

Thanks again…