Resolution:
We believe we know what is causing the growth in size of your subscriber's ledger file.

Each sendRequest() call creates an inbox and a listener is setup on that inbox.  When the request reaches the other application, the reply is sent to that specific inbox (extracted from the message).

Here is an excerpt from the TIBCO Rendezvous documentation that explains why there is memory growth:

TIBCO Rendezvous Java Reference, Chapter 9 "Certified Message Delivery", method TibrvCmTransport.removeSendState():
-------
In some programs subject names are useful only for a limited time; after that time, they are never used again.  For example, consider a server program that sends certified reply messages to client inbox names; it only sends one reply message to each inbox, and after delivery is confirmed and complete, that inbox name is obsolete.  Nonetheless, a record for that inbox name remains in the server's ledger.

As such obsolete records accumulate, the ledger size grows.  To counteract this growth, programs can use this method to discard obsolete subject records from the ledger.

The DELIVERY.COMPLETE advisory is a good opportunity to clear the send state of an obsolete subject.  Another strategy is to review the ledger periodically, sweeping to detect and remove all obsolete subjects.
-------

So, this means that the application (your BW subscriber), which is using the sendReply() method from a CM transport will use increasingly more memory.  You will have to use the above method (removeSendState) to reclaim ledger space from obsolete subjects (which you can find by monitoring the subject element of the DELIVERY.COMPLETE advisory).

In addition to this you will also have to manually pre-register the listener before calling TibrvCmTransport.sendReply() i.e. pre-register the sendRequest() application with the sendReply() application (you need to add your BW publisher as a listener to the BW subscriber).

This has to be done to ensure all messages are certified, otherwise you will not see the subjects in the DELIVERY.COMPLETE advisories.

NOTE: A change was made in TIBCO Rendezvous 7.2 so that the the sendReply() method will automatically pre-register the listener if the request was sent by a sendRequest() call.


On a similar note, this phenomenon has been observed even when the requesting transport is *not* a CM correspondent, which means that the DELIVERY.CONFIRM advisory cannot be expected here as there is no certified agreement in place.

If there is no certified agreement in place between the two concerned transports, the incoming messages (requests) would not carry a sequence number (TibrvCmMsg.getSequence() call returns “0”).  So, you could check for messages having reply subjects that start with the string “_INBOX.”, and that do not have a sequence number, before replying.  In such cases, writing of the “_INBOX.” record in the ledger file of the server can be avoided by using the reliable transport to send the reply, instead of the certified transport.