I'm running IMQ 3.5 SP1 with Java 1.4.2_02 on RedHat Linux.
I have set imq.persist.file.sync.enabled=true
in /opt/imq/lib/props/broker/default.properties, but I have noticed that performance improves when there my durable subscribers are not connected to their topics.
So my question is: how can I verify that message persistance is enabled? It's not mentioned when querying the broker.
Thanks, Zac.
If a topic has no durable subscribers then messages are not persisted even if sent as PERSISTENT.
If the topic has at least one durable subscriber, (active or not), then PERSISTENT messages are persisted.
One way to verify is to attach a durable subscriber to the topic (to create a durable subscription). Close the durable subscriber. Send 5 persistent messages (should be held in the durable subscription). Restart the broker. Reattach the durable subscriber, and verify it gets the messages.
I understand how durable subscriptions work.
I have enabled the file sync, and I thought this means that a message is supposed to be persisted before the publisher returns, regardless of a durable subscription being active or not.
How can I verify that the message is bing persisted when the durable subscriber is active? Why would I see a performance improvement from the publisher side when the durable subscription is not active?
I just want to make sure that /opt/imq/lib/props/broker/default.properties is the appropriate place to set this attribute. imqcmd query bkr
doesn't seem to report persistance settings.
How can I verify that my messages are being persisted when all durable subscibers are active?
Why do the message producers speed up when the durable subscribers are not active?
Persistence is controlled by the client when it sends the message.
That's why there isn't a way to see if persistence is set by
querying the broker. The imq.persist.file.sync.enabled=true
property controls whether the broker will sync to disk each
persistent message it receives or allow the OS buffer writes
to the disk (several messages may get pushed to disk in one
write).
If you send persistent messages to a broker and the broker
only has normal subscribers there is no need for the broker
to persist the messages.This is an optimization we can make
based on how the JMS spec defines Topic behavior.If a
durable subscriber exists, either active or inactive then the broker
must persist the messages - because if the broker were to be
restarted the persistent messages would need to be available
to the durable subscriber when it becomes active again.
Sending persistent messages to an active durable subscriber will
be the slowest because the broker has to both persist, route and
handle the ack back from the durable subscriber.
Sending persistent messages to an inactive durable subscriber
will be a bit faster because the broker still must persist the
message but it doesn't need to route or handle the ack because
the durable is inactive.
Sending persistent messages to only normal subscribers will be
the fastest because the broker doesn't need to persist the
message.
How can you test if the messages are being persisted? Stop
and restart the broker. If the messages are persistent they
will still be there. If they are not persistent they will be gone.
Hope this helps.
Chris
Thanks for your reply. As I mentioned before, I understand the whys and wherefores of durable subscriptions. I just need a way to verify that messages are, in fact, being persisted for an active durable subscriber. I set the option so that they would be, and now I'd like to verify that they are.
> [steps involved when sending persistent messages published to a topic with active vs. inactive durable subscribers]
This seems strange to me; if steps aren't taken (routing and acking) when a durable subscriber is inactive until it becomes active again, why can't these steps be taken by a different thread outside of the publishing process? That it takes longer when all parts of the system are active seems less-than-ideal.
> [testing if the messages are being persisted]
If my durable subscribers are active - the condition I'm interested in - then won't the messages have been delivered to the subscribers already? There would be no persisted messages remaining after stopping the broker .
> This seems strange to me; if steps aren't taken
> (routing and acking) when a durable subscriber is
> inactive until it becomes active again, why
> can't these steps be taken by a different thread
> outside of the publishing process? That it takes
> longer when all parts of the system are active seems
> less-than-ideal.
They are handled by different threads but work still needs
to be performed by the JVM.My point is an active durable
subscriber requires the broker to do more work than if the
durable was inactive.Threads help manage that work but
it doesn't make the cost of performing that work go to zero.
>
> > [testing if the messages are being persisted]
>
> If my durable subscribers are active - the condition
> I'm interested in - then won't the messages have been
> delivered to the subscribers already? There would be
> no persisted messages remaining after stopping the
> broker .
If your durable subscriber has acknowledged the message
then the broker will not longer be maintaining the persistent
copy.
Here's one way to test persistence:
1) Start your durable subscriber (it subsribes to a topic)
2) Kill your durable subscriber (the subscription remains,
the broker see it as an inactive durable sub)
3) Send some persistent messages to the topic the durable is
subscribed to.
4) Restart the broker.
5) Restart your durable subscriber. If the messages were persisted
they would be delivered to the durable sub. If they weren't then
they were lost when the broker was restarted.
Chris
Ok.
What about slowing down the rate (use a sleep) the durable
consumes messages?Messages will accumulate in the
broker. Restart the broker, use imqcmd to query the destination
to see the messages are still there or restart the durable sub and
see that it receives all the messages the producer sent prior
to the broker being restarted.
The best I could come up with:
1) Start the durable subscriber on <TopicName>.
2) Don't send any messages for at least a minute.
3) Send a message to <TopicName>.
4) Verify that the persistance file <broker>/fs350/message/T<TopicName>/vrfile has been touched (time stamp updated to the current time).
