Layer7 API Management

Hi,

I'm getting the message "Execution failed. Reason: Error writing object 'null'." while trying a migrateIn. Still, after checking the target gateway, the migrated changes are there.

This is what I see in the gmu log:

INFO: Running Command: migrateIn
Nov 27, 2017 3:57:22 PM com.ca.gateway.rest.commandline.command.Command runCommand
WARNING: Error executing command
java.io.IOException: Error writing object 'null'.
at com.ca.gateway.rest.api.ManagedObjectUtils.unmarshal(Unknown Source)
at com.ca.gateway.rest.api.resource.impl.BundleResource.importBundle(Unknown Source)
at com.ca.gateway.rest.commandline.command.MigrateInCommand.a(Unknown Source)
at com.ca.gateway.rest.commandline.command.MigrateInCommand.run(Unknown Source)
at com.ca.gateway.rest.commandline.command.GatewayCommand.run(Unknown Source)
at com.ca.gateway.rest.commandline.command.Command.runCommand(Unknown Source)
at com.ca.gateway.rest.commandline.Main.main(Unknown Source)
Caused by: javax.xml.bind.UnmarshalException
- with linked exception:
[org.xml.sax.SAXParseException; Premature end of file.]
at javax.xml.bind.helpers.AbstractUnmarshallerImpl.createUnmarshalException(Unknown Source)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.createUnmarshalException(UnmarshallerImpl.java:514)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:215)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:190)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:241)
... 7 more
Caused by: org.xml.sax.SAXParseException; Premature end of file.
at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:211)
... 9 more

Any ideas?

-Jaime

Hi Jaime,

the bundle file is in xml format, right?

it seems the xml file is not in good format, or truncated.

Regards,

Mark

Hey Mark,

No, we're using a directory bundle. I've noticed that this error happens when the bundle takes a while to complete. Sometimes, re-trying makes the error go away. I haven't found a root cause for this yet.

Thanks,

-Jaime

You might try to add the --readTimeout <read timeout> argument to your migrateIn command. It's in milliseconds.

Hey Zhijun,

setting the readTimeout didn't work. I set it to 300000, but got the error after 3 mins of running the migrateIn

Hi Jaime

I think Mark_HE is on the right track for this problem.  We had exactly the same error.

The error stacktrace seems to imply the error may be in the .xml format but it is not.   The error : 

java.io.IOException: Error writing object 'null'.

Is the clue, the xml file format is fine, the problem is when it writes the REST request across the network to the target machine.   And it is the target machine that had the problem (in our case it was refusing the connection, but in your case a timeout seems a reasonable guess for the cause). 

1. If the timeout does not resolve your issue you could enable the -Djavax.net.debug=all  tracing in the GMU utility,

With the ssl network trace, you can see the exact REST request and response: 

It was done by editing the file : 

GatewayMigrationUtility.bat

"%JAVA_TO_USE%" -Djavax.net.debug=all -Dfile.encoding=UTF-8 -DGMU_HOME=%jarDir% -jar "%jarDir%GatewayMigrationUtility.jar" %ARGS%

Unix is similar: 

GatewayMigrationUtility.sh

"${JAVA_HOME}/bin/java" ${JAVA_OPTS} -Djavax.net.debug=all  -DGMU_HOME=$(dirname $0) -jar "$(dirname $0)/GatewayMigrationUtility.jar" "$@"

That was how we identified our issue.

2. Check Gateway audit logs. 

Since it is the Gateway rest provider that either gives the error or takes too long, then there is likely to be some trace in the gw audit or log files for the target machine that may help isolate the problem. 

Hope that help, if the extended timeout does not resolve the issue. 

Cheers - Mark

Thanks, Mark. I'll try your suggestions, since the readTimeout didn't work.

We faced the same issue with one of our environment where we have imported the custom assertion (maths assertion)  before hand. Same MigrateIn worked on the server where this assertion was not installed prior.