I'm getting the following error in the error log:
<Aug 3, 2009 9:36:17 AM EDT> <Error> <com.adobe.formServer.PA.XMLFormAgentWrapper> <BEA-000000> <ALC-FRM-001-013: XMLFormFactory, PAexecute failure: "Stream corrupted at 65268: tried to read string of length 4e746e65">
<Aug 3, 2009 9:36:17 AM EDT> <Error> <com.adobe.idp.workflow.dsc.invoker.WorkflowDSCInvoker> <BEA-000000> <An exception was thrown with name com.adobe.livecycle.formsservice.exception.RenderFormException message:org.omg.CORBA.MARSHAL: Stream corrupted at 65268: tried to read string of length 4e746e65 vmcid: 0x0 minor code: 0 completed: No while invoking service FormsService and operation renderPDFForm and no fault routes were found to be configured.>
Anyone have a clue? I've seen this before; it's completely random. We can render a form on our dev system fine, and then try the same .xdp on our prod server with the same data and have this error pop up. The same form will work fine 99% of the time; this happens only occasionally.
I'm getting the same type of error. Were you able to figure out this error? My scenario in a Production environment is the same. I get this error randomly. I save off the XML and XDP template and run it through the FormsIVS and OutputIVS tests. The IVS tests pass, so it's not the XML or XDP. I'd like to avoid telling users to try again.
An update for users on what is the fix in my stream corruption situation. Turn off native IO on the managed WebLogic servers. Turn off the option by going to the WebLogic admin console GUI, managed server, Configuration tab, Tuning tab and uncheck Enable Native IO. Restart the managed server(s). There is a performance decrease by disabling this option. Run tests to see if the performance decrease is acceptable in your environment. I did upgrade to newer software while trying to get a permanent fix which I will describe below.
I was on Adobe LiveCycle ES Update 1 (8.2.1), Windows 2003 (32-bit), JRockit R28 (1.5.0_24), WebLogic 9.2 MP4 (32-bit), Oracle 10.2.0.4 (Solaris 10, 64-bit) when I first experienced the stream corruption problem. WebLogic support and Adobe support didn't solve the problem on that platform. The stream corrupt error would happen even if there was no load on the servers. The error could happen on a 1 node standalone server or multiple node clustered servers. I was only able to reproduce the problem in my development environment by running it through a batch job. I submitted 5 concurrent PDF requests at a time to process the 30,000+ total. I would get around 1 stream corruption error for every 1000 processed. I had to keep resubmitting the request to clear out the failed requests.
I started using Adobe LiveCycle ES3 on a newer WebLogic to see if the problem would be solved. I went to Adobe LiveCycle ES3 SP1, Windows 2008 (64-bit), Sun 188.8.131.52 (64-bit), WebLogic 10.3.5 (64-bit), Oracle 184.108.40.206 (Solaris 10, 64-bit). The stream corruption error was still there using my batch job test from the previous version.
I tried experimenting with JBoss 5.1 as the app server and the other components the same. I configured JBoss the same way that Adobe documentation states for a JBoss install. My batch job is successful. I don't get the stream corruption error. I tried my batch job multiple times on JBoss and didn't get an error, so I'm leaning towards the WebLogic app server as the problem.
I worked with Adobe and WebLogic support, but mostly with WebLogic in trying to get this problem resolved. They suggested many things to try, but none of them worked until I disabled native IO. Turning off native IO fixed the stream corruption problems. The stream corrupt problem could be a combination of WebLogic and Windows.
Updating this post to let you guys know of the WebLogic fix. The problem is documented in Oracle Support's ID 1543065.1 (CORBA.MARSHAL Stream Corruption Error [ID 1543065.1]). WebLogic released patch 14691998 for WLS 10.3.5. You will probably have to ask WebLogic to backport the patch to a different WLS version if you aren't on 10.3.5. WebLogic states the problem is fixed in WLS 12.1.2.
The performance decrease that I described above was around 30% when I disabled native I/O. I put in the patch 14691998and enabled native I/O again in a recent test. The performance was normal again. I gained back the 30% and processed 70,000 PDFs without a stream corruption error.