Prior to trying to upgrade, which is what Support told me to do when I reported this problem to them, when some very large payloads are sent with many repeating groups of XML data inside a single block, the web service call fails. This call is coming from an Oracle SOA framework and they get this response back from the call:
[b]
[/b]
I could find no logs to look through.
At this point I don’t know if this is WSStack failing, Axis2 failing, Tomcat failing, a resource issue on the Linux server, or something else, but this service call works with smaller payloads. It never reaches the EntireX Broker at all though when this response is received.
Has anyone seen this before or would know how I can resolve it?
there has been a bug report at Sun/Oracle for exactly this error message (“Resetting to invalid mark”).
This has been corrected with Java 1.6 b79. You should check the Java version you are using for running your Tomcat.
I am happy to hear this is a known issue with Java. Does Java come with WSStack, or is the Java version completely independent of the WSStack version? If I upgrade to WSStack 9.6 (with latest fixes from Update Manager), can I assume it will include Java updates as well, or should I be following up with the Linux admins for this?
One would think these would have the fixes included in 1.6 B79 unless they actually preceded the development of this fix and it is included in a later build of 1.7. Do you have access to reference the minimum build of 1.7 that includes such a fix?
I may be able to get this upgraded to the proper level if I know what that was. You are correct we are running under Tomcat other than the SAG Common Tomcat system. While I just learned yesterday is that, while previous versions of WSStack were supported under other app servers (other Tomcat, webLogic, IIS, etc), as of v9.6, only SAG Common Tomcat is supported. I don’t know if this is widely known or understood and may cause an uproar as many organizations have enterprise standards they follow for acceptable app servers/web servers and would cause at least disruption in having to migrate to a non-standard Tomcat for this one application (WSStack).
It’s what I was told on the phone with support (Miguel Pujol). He was likely reading that from R&D’s notes on the SR (either 5155352 or 1092484). I plan to write up a business case for why these previously-supported app servers should continue to be supported and will hope the policy change is reversed.
As for Java 1.7.0_67, we got the same response back:
Unless otherwise mentioned all products only support the application server that is included with the suite.
…
EntireX and ApplinX support additional Application Servers.
See the Release Notes of these products.
What you are saying then is perhaps the first part of that:
…was what was passed along to me without regard for the EntireX documentation that supersedes that by saying:
Since stand-alone Tomcat supports J2EE 1.5, I should have no problem being supported for WSStack 9.6 for EntireX’s use on the existing server it is deployed to. Is that correct?
As for the issue, I will deploy 9.6 now to SIT & UAT replacing 8.2 and have the payload re-tested that failed. If it fails again, I will be capturing an axis2.log file and will open a new support request since v9.6 is under support (v8.2 was dropped on June 30th).
After deploying Web Services Stack 9.6.0.0.278 (fix 3 according to Update Manager), the issue we had under v8.2 has been resolved. Large payloads that died under the old version complete successfully under the new one.
The Java update might have been necessary but it alone did not solve the problem. Something in WSStack was also improved and was necessary. The old version was Web Services Stack 8.2.2.0.234.