IBM Support

PI14184: eXtreme Data Format (XDF) serialization and deserialization can be slow with large graphs of Objects.

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • Closed as program error.

Error description

  • As the number of objects in a graph of objects increases, the
    amount of time to do a get/commit increases when doing
    serialization and deserialization of objects also increases.
    For these type of objects, as you add more threads it gets
    worse because of bottlenecks that are preventing threads from
    getting CPU cycles.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  Users of eXtreme Scale who use the eXtreme  *
    *                  Data Format (XDF) function and have very    *
    *                  large graphs of objects that they store in  *
    *                  the grid.  Additionally some or all of the  *
    *                  objects in the large graph need to make     *
    *                  use of readObject and/or writeObject or     *
    *                  be externalizable.                          *
    ****************************************************************
    * PROBLEM DESCRIPTION: As the number of threads using the      *
    *                      grid increases, response time           *
    *                      decreases with large graphs of          *
    *                      objects.                                *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    Two bottlenecks in the XDF code were identified:
    -For the first bottleneck, where the code was accessing a shard
    or JVM scoped object that required synchronization, it was
    changed to cache the result for the length of the
    serialization/deserialization instead of accessing the
    resource on each object in the graph.
    -For the second bottleneck, a method that was synchronized was
    changed to no longer require synchronization.
    

Problem conclusion

  • An interim fix is available for this APAR.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PI14184

  • Reported component name

    WS EXTREME SCAL

  • Reported component ID

    5724X6702

  • Reported release

    860

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2014-03-21

  • Closed date

    2014-04-15

  • Last modified date

    2014-04-15

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    WS EXTREME SCAL

  • Fixed component ID

    5724X6702

Applicable component levels

  • R860 PSY

       UP

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSTVLU","label":"WebSphere eXtreme Scale"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"860","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
15 April 2014