JAS_MSG431: Could not Fetch Serialized Obj....

DBohner-(db)

Legendary Poster
Interesting issue:

We have several BASE objects - that we cannot pull up via the web client.

For example, we FastPath to P31113|ZJDE0001 - the initial form opens. We do a Find, select a row, then do a Row Exit to Revisions - and KaBling; we get an error message:
"COULD NOT LOAD FORM: P31113|ZJDE0001
JAS_MSG431: Fetch Serialized Object Failed. Please contact your systems administrator."

To my knowledge - we've done just about everything to get this object up and running 'correctly'.

What we've done:
Put the object in a project, checked it out, added a comment line, saved, checked back in, added all Versions to the Project then Promoted/Built/Deployed. Same error message!

When these objects are run on a FAT Client, we don't get the issue (of course, right).

This issue is in only one environment.

If there are any suggestions - I am ready to read!

This Client: Sun|Oracle 10G|E812|8.96.10

(db)
 
Daniel,

I see you're on 8.12. Do you have the auto package discovery enabled? If so, perhaps you could take an outage, or during a designated maintenance window, truncate the serialized object tables for that environment and then deploy a new full package?

Since this issue is only happening in one environment, I'd make an educated guess that you have corrupted specs in the serialized object tables for that environment.

I've seen this problem occur before in 8.11 SP1, and all the package builds, generating of objects, refrshing of web specs and even restarting JAS services didn't help.

If you know what you're doing, you could manually delete all the associated rows from the F989998/F989999 tables, or you could take an outage and truncate the tables, then perform a full gen (if not using the auto package discovery option).
 
That we've done all C's Suggestions - and AutoDiscovery is on.

More ideas?

(db)
 
Curious - perhaps you can try by turning off the auto discovery, then map the jdbj.ini to a "working" Central Objects" datasource. I've done this before and it helped me troubleshoot the issue.

If this isn't a production environment, it could be a way to get the users into the app while you sort out the problem on the back-end. However, there would likely be several inconsistencies, so best to try after hours when there are no users in the system.
 
Hi,

Are you having many Java Heap and Core Dumps on your
Web Servers? I noticed that many of these weird JASMSG341
errors appeared right before one of those Java dumps.
Have you checked memory usage on your Web server?
What about disk utilization? Is there place for
temporaries?
 
My first response would have been to do what has already been suggested... gen the object in that environment for that web server. But if you've ruled that out then I have another idea. When we converted to 8.12, we had a custom menu that referenced a version that JDE removed and so trying to call it generated a similar (if not the same) web exception error. I realize that this is a ZJDE version, so that is unlikely, but there may still be a problem with that version. Have you modified this application or it's processing options? Perhaps there is a disconnect between the version and processing options and so when you try to instantiate the version from a menu, it chokes. Try changing the version on the menu to another one that you're sure exists and try running it. If it works, then the problem is definitely the version.
 
OK - the issue in this one case was 'Developer Error'. At some point in
time, custom code was added to the 'OK Post Button' event rules. The
developer left a hanging 'ENDIF' in the code. Apparently, the hanging ENDIF
works fine on FAT, but when the Web-Magic occurs - there is a crash in the
process bringing the 'corrupt' specs to the web.

This was found two ways. One by debugging the JAS logs (they had to be
turned on) and doing a great deal of deciphering. The other (easier, and
may not always reveal) was to copy the object and do an ER Compare between
the two. When doing the ERC, the Hanging ENDIF does not get copied to the
new specs.

One other oddity. Any 'commented out' comments are 'uncommented' when you
copy objects... 8.12

(db)
--
 
Back
Top