IBM Support

PI31775: JMS MESSAGES BUILDUP ON THE DESTINATION WHEN TOPICSPACE MAPPING IS USED ACROSS MULTIPLE BUSES

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • In a multi-bus over multi-cell configuration, each with the
    same copy of a publish/subscribe pair of applications running
    on a single server or cluster, where the intent is to have
    the application publish a message representing an event from
    any cell and have the message to be consumed by all the cells.
    
    Scenario:
    
    - 3 buses, A, B and C
    
    - Buses A and B connected to C through direct Foreign Bus
    connection
    - Same Topic Space destination defined in all buses
    
    - Topic space mapped A to C, C to A, B to C, C to B
    
    - Same topic used by publish message producer (Connection
    Factory,Topic) and Activation Specification (durable
    subscriber)
    - After initial server startup, messages published from A
    behave as expected. MDB is driven in A,B and C.
    
    - Messages then subsequently published from B do not get
    delivered.
    - Message on C Link transmitters to A Publish/Subscribe
    type is CWSIP0911W. Individual messages on the Link
    transmitter streams are in a "Pending Acknowledgement"
    state
    - Message engine on C is restarted and messages re-published
    from B flow normally. But now, messages published on A
    pile up.
    This behavior is noted on both WebSphere Application Server
    V8.0.0.9 and V8.5.5.2
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  Users of the default messaging provider for *
    *                  IBM WebSphere Application Server            *
    ****************************************************************
    * PROBLEM DESCRIPTION: In a multi-bus configuration where      *
    *                      topicspace mappings are used across     *
    *                      these buses, the messages get stuck     *
    *                      at intermediate messaging engines       *
    *                      (MEs).                                  *
    ****************************************************************
    * RECOMMENDATION:  NONE                                        *
    ****************************************************************
    The following example configuration recreates the problem.
    1. Configure three cells namely A, B and C.
    2. Create a SIBus in all the above cells and add a server as
    bus
    member.
    3. Create a topicspace with the same name say TP1 in all the
    above Cells
    4. Create Foreign Bus connections as below.
    from A --> C and C --> A
    from B --> C and C --> B
    The above configuration creates SIBLinks
    5. Create topicspace mappings for the topicspace TP1 as below.
    from A --> C and C --> A
    from B --> C and C --> B
    6. Create a JMS topic say JMSTOPIC on all the cells on the
    topicspace TP1
    7. Deploy a message publisher application all the cells that
    produces messages to JMSTOPIC
    8. Deploy a message subscriber application across all the Cells
    that consume messages from JMSTOPIC
    9. The intention of the above configuration is that if a
    message
    get published at one cell on the JMSTOPIC, it will be consumed
    by the local subscriber and the subscribers running in the
    other
    two cells on the same JMSTOPIC.
    When a message is published on the JMSTOPIC on Cell A then it
    should get consumed by the following subscribers
    1. The local subscriber deployed on cell A that consumes
    messages from JMSTOPIC.
    2. Since topicspace mappings is configured
    from A --> C and C --> A
    The message should get sent to cell C and the subscriber
    running in the cell C should get a copy of the message.
    3. Since topicspace mappings is configured
    from B --> C and C --> B
    The message should get sent to cell B from cell C and the
    subscriber running in the cell B should get a copy of the
    message.
    However, the messages that are sent from A to C get piled up in
    the SIBLink transmitter with state "Pending Acknowledgement".
    The same is the case for the messages published at the other
    two cells B or C. They all get piled up at the corresponding
    link transmitters.
    

Problem conclusion

  • The messages get stuck and stop flowing between MEs due to
    creating the internal output transmission stream of a target ME
    with the tick value of the message which was actually sent by
    the same ME.  The code changes have been made to properly
    handle these ticks by writing silence in the output streams.
    
    
    The fix for this APAR is currently targeted for inclusion in
    fix packs 7.0.0.39, 8.0.0.11 and 8.5.5.6.  Please refer to the
    Recommended Updates page for delivery information:
    http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
    

Temporary fix

Comments

APAR Information

  • APAR number

    PI31775

  • Reported component name

    WAS SIB & SIBWS

  • Reported component ID

    620800101

  • Reported release

    800

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2014-12-18

  • Closed date

    2015-02-23

  • Last modified date

    2015-02-23

  • 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

    WAS SIB & SIBWS

  • Fixed component ID

    620800101

Applicable component levels

  • R800 PSY

       UP

  • R850 PSY

       UP



Document information

More support for: WebSphere Application Server
Service Integration Technology

Software version: 8.0

Reference #: PI31775

Modified date: 23 February 2015