Interesting. I must have a flawed understanding of durable subscribers. I thought it signified a consumer that can disconnect/reconnect and any messages that arrived in the time while the subscriber was disconnected will still be delivered. Cool, but not what we thought we needed.
Intuitively to me the above "durable subscriber" concept does not preclude having persistent messages in effect for non-durable subscribers: the thought being if the broker crashes we still want the (in "memory") as-yet-undelivered messages to be delivered after failover occurs. we really have no need for disconnecting/reconnecting subscribers while our app is running - the subscribers connect and stay connected. I'm sure I did not explain that very clearly :) I will try using a durable subscriber and see if my messages magically apperar in the db. THANKS! I appreciate your response. -- View this message in context: http://activemq.2283324.n4.nabble.com/Where-s-the-records-in-my-jdbc-persistence-store-tp4677577p4677588.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
