Hi,

I am publishing a guaranteed document. I am wondering, what happens to the publishing document, if no trigger available to subscribe it?? Does it stays on the broker forever?? if not how long?? Will it going to effect the Broker memory??

Thanks for any help,
CL

If there is a subscription, but the subscribing client isn’t running, the document will stay on the queue forever. Yes, it can impact Broker storage and memory.

If there is no subscription, the document will be thrown away. However, with 6.1 or 6.5 (I can’t remember when it was introduced) there is an option to set up a “dead letter queue” which is where all documents with no subscribers go. With that you can discover setup issues, old document types, etc.

The default behavior - a “time to live setting” in conjunction with a “discard” setting for the document can be set in the properties of the document type.

Not that a guaranteed document with a ttl makes a whole lot of sense, but it is there if you want it!

One of my past clients used this. Then they kept asking why guaranteed documents kept getting “lost” when the brokers got busy.

The TTL is honored, and events removed from the queue, only when a client asks for the “next” event. If no client ever connects again to the queue, the event will remain forever. There is no thread that purges expired events from queues.

Quite correct!

thanks guys,

I too had seen the same phenomenon that Reamon has mentioned. If the client does not subscribe then the documents stay in the broker queue and would not get deleted unless the client document queue is deleted or the client is deleted.
It just consumes the borker memory.

“If the client does not subscribe…” isn’t quite accurate. If a client doesn’t subscribe to a document type, no documents of that type will stay in the Broker queue, even if the client queue exists. The accurate statement is “If a client that has a subscription to a document type isn’t connected to the Broker, and actively retrieving documents, then the documents will stay on the client queue.”

When a client first connects to the Broker, a client queue is created. Then the client can subscribe to 1 or more document types through that queue. If the queue properties are DESTROY ON DISCONNECT and the client disconnects, the subscriptions and queue will be destroyed.

If the queue properties are EXPLICITY DESTROY and the client disconnects (but doesn’t explicitly destroy the queue) the queue and its associated subscription(s) remain. This is the scenario in which documents can build up on the Broker.

Client queues created by IS normally fall in the latter category. If you’ve deleted all Broker document triggers for a given document type from IS, you must manually delete the associated client queue from the Broker using Broker Admin.

Thanks alot reamon

Also, i wouldn’t really categorize this as a phenomenon - it is designed this way on purpose.

Rob has clarified quite a bit (Thanks Rob!!!), i would add to it that the queue design is explicitly designed this way to allow guaranteed documents to persist beyond the lifespan of any particular client when set up in explicit destroy mode. This helps to insulates your guaranteed documents against unexpected client disconnection, and also allows for a client to intermittently “poll” the queue without needing to stay attached all the time.