I think the current behavior of stopping the networkConnector when it will be impossible for it to do any work (because we can't write to the persistent store) is the right behavior; having a zombie networkConnector hanging around just hoping for the store to become available sounds like an awful option for a number of reasons, one of which is that it will "steal" as many messages as its prefetch buffer size so your consumers will be missing messages. And no, simply ignoring all IOExceptions is not the right approach; what does it mean to ignore an EOFException or a SocketTimeoutException?
But it seems reasonable to have a periodic retry if the networkConnector fails. Submit an enhancement request in JIRA and maybe someone will implement it. (Or implement it yourself and submit a patch or a pull request, if you want it sooner.) In the meantime, disabling statement pooling should let you work around this. Or if you think statement pooling is an absolute must-have, you could move to Oracle, since their driver can do its own pooling of both connections and statements, if I'm remembering correctly. Tim On Mar 10, 2016 4:43 PM, "alt_alt" <alt_...@163.com> wrote: > Hi Tim, > Thanks for your useful tips. I agree that there may be some configuration > problem in JDBS store, but I don't think the network connector should just > be stopped and never be restarted again without restarting ActiveMQ service > due to exeption in JDBC store. I don't think it is an acceptable behavior > for ActiveMQ network relying on the message forwarding. Maybe you could add > some feature to let the network still alive even such exception happens. > For > example, adding a peoperty of ignoreLocalIOException for networkConnector? > > Best Regards > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Failed-network-connector-can-not-be-re-established-tp4709054p4709183.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
