Skip to main content

This content has been archived and is no longer being updated. Links may not function; however, this content may be relevant to outdated versions of the product.

Support Article

Sporadic blob corruption during commit of work objects



Occasionally, work objects get corrupted; they cannot be opened. There is no pattern to the corruption. Once corrupted, they cannot be repaired.

Error Messages

You might see a popup window with a big red X with a message such as below:

"Problem opening instance MyClassStructure-WORK W-xxxx from the database -- it has a bad instance class <none>: code: <none>"
The most significant part of the error is the fact that "<none>" is displayed as the instance class. This usually indicates corruption of the blob.

Once you suspect blob corruption and you have identified a particular record as corrupted (for example, W-1234), then you can confirm if it is a blob corruption through the following SQL (this example is tuned for Oracle, you may require a slight change for another database product) which will generate the "truncated binary stream" error:

> SQL> select pr_read_from_stream('pxObjClass',pzinskey,pzpvstream) from

> MYDATABASETABLE_WORK where pzinskey like '%W-1234%';

> select pr_read_from_stream('pxObjClass',pzinskey,pzpvstream) from

> MYDATABASETABLE_WORK_WORK where pzinskey like '%W-1234%'

> *

> ERROR at line 1:

> ORA-29532: Java call terminated by uncaught Java exception:


> *BadStreamDataException:*

Truncated binary stream encountered; expected decompressed size of

> 2370997, but

> actually got 1410181

The Corrupt Blob Utility (CBU) can be used to analyze all the work objects in the class, and list all the work objects which are corrupted. The Corrupt Blob Utility is available on the Pega PDN.

You may request a diagnostic patch (HFix-9726 is available for PRPC 6.2 SP2 and HFix-6137 for PRPC 6.2 SP1) which will catch the corruption if it occurs as the record is committed. The patch will display the sizes altered during a corruption event as displayed in the following debug lines:

2014-08-04 03:13:42,046 [ PegaRULES-Batch-1] [ STANDARD] [ ProjectFW:01.01.03] (ss.DatabaseImpl.CompressionLog) DEBUG - Current pzInsKey: MyClassStructure-WORK P-2070
2014-08-04 03:13:42,093 [ PegaRULES-Batch-1] [ STANDARD] [ ProjectFW:01.01.03] (ss.DatabaseImpl.CompressionLog) DEBUG - Found comparison error after commit.
2014-08-04 03:13:42,093 [ PegaRULES-Batch-1] [ STANDARD] [ ProjectFW:01.01.03] (ss.DatabaseImpl.CompressionLog) DEBUG - Original byte array: [[email protected]
2014-08-04 03:13:42,093 [ PegaRULES-Batch-1] [ STANDARD] [ ProjectFW:01.01.03] (ss.DatabaseImpl.CompressionLog) DEBUG - Post-commit byte array: [[email protected]

If you retrieve the raw blob through a direct SQL command and examine it in a hex editor, you may observe that the trailing N bytes are all null. This also is an indication of blob corruption.

Steps to Reproduce

This is a sporadic issue and there is no specific use case to replicate the issue.

Root Cause

The root cause of this problem has never been determined, but we are sure it is a bug in the older version of the JVM/JDK, perhaps in the way it interfaces with other (newer) components of the environment.

When the problem is suspected, contact Pegasystems right away. Pega can construct a database trigger that detects the null-trailing blobs and aborts the transaction, preventing the creation of additional corrupt work objects. 



Upgrading your JVM/JDK to newer versions will resolve the issue. 

Suggest Edit

Published January 31, 2016 - Updated October 8, 2020

Did you find this content helpful? Yes No

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us