Hey Tim, the demand forwarding network connector should automatically attempt
to reconnect. At one point, years ago, I tried removing the failover
transport and sticking to the reties there because of other issues and found
that without the failover transport, the reconnects are not as reliable.
Art, it's always been my understanding that static TCP transports would
reconnect when used as a networkConnector, and that the only reason to use
failover is if you have multiple brokers. Is that not accurate?
On Mar 12, 2016 11:17 PM, "artnaseef" wrote:
> Ahh, here it is from the original post
Thanks for you advice for tuning JDBC and configuration of network connector,
and we'll definitely try that. But it looks like the network connector is
closed from the source side due to local JDBC exception(the source side
means the source ActiveMQ server of forwarded message via network
connector
Other possibilities are a bug in ActiveMQ code where we fail to close() our
PreparedStatements in certain cases, and a bug in the connection pool.
On Mar 12, 2016 11:13 PM, "artnaseef" wrote:
> Any idea what is causing "Borrow prepareStatement from pool failed"?
>
> The only possible cause coming
Ahh, here it is from the original post:
uri="static://(tcp://10.102.44.181:61616)"
try this instead:
uri="static://(failover://(tcp://10.102.44.181:61616))"
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Failed-network-connector-can-not-be-re-established-tp4709054p47
Also - network connectors typically automatically reconnect.
Is the network connector configured to use the failover transport? If not,
try adding it to see if that helps to eliminate the problem.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Failed-network-connector-
Any idea what is causing "Borrow prepareStatement from pool failed"?
The only possible cause coming to mind right now is a pool that is exhausted
- meaning there are long-running DB operations. If that's the case, then
tuning the DB, moving to another store, or possible tuning the pooling
setting
Hi Tim,
Thanks for your advice, I've already filed a jira ticket for it. It is
AMQ-6200
Add a retry mechanism would be a decent solution to my problem, and I agree
with you that just ignoring the exception is not a good one. Please add this
feature to future ActiveMQ release. We can disable pooling
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 o
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 b
I've never run ActiveMQ with the JDBC persistence store, so I can't answer
that question directly, and I don't get the sense that most of the people
on this mailing list have either, so you may not be able to answer that
question other than by trying it. With that being said, I wouldn't expect
it
Hi Tim,
Really appreciated for your reply, here is the datasource configuration,
just the same as the one shown in ActiveMQ webpage.
What's the performance impact if I set poolPreparedStatements to false?
Best Regards
--
View this message
Hi Tim,
Really appreciated for your reply, here is the datasource configuration,
just the same as the one shown in ActiveMQ webpage.
What's the performance impact if I set poolPreparedStatements to false?
Best Regards
--
View this message in c
"JDBC Failure: Borrow prepareStatement from pool failed"
Your problem is in the JDBC store (specifically the connection pool), whose
configuration you didn't post or tell us anything about.
One possible workaround would be to simply tell the DataSource to not pool
prepared statements via
https://
14 matches
Mail list logo
