am trying to start the ActiveMQ 5.11 and I see a WARNING
as below:
WARN | Transport Connection to: tcp://127.0.0.1:40890 failed: java.io.EOFExc
So, I finally got to the root cause of this. This WARNING
comes because the way networkConnector works and configured. I had posted this on the activemq community here - http://activemq.2283324.n4.nabble.com/java-io-EOFException-when-ActiveMQ-starts-td4717598.html
When networkConnector
is used, activemq tries to connect to the broker configured. In my case, I was trying to self-connect to the broker and that is why it was rejecting the connection. The same was pointed by Tim in the community.
I've never tried configuring a broker with a static networkConnector connected to itself (why would I, it's a useless configuration), but it wouldn't surprise me if the broker rejected that self-connection, which could result in the EOFException you saw. It's also possible that there's something wrong with your SSL configuration as you suggested; there's no good way in a mailing list discussion to check whether your truststore trusts your keystore and the certs are being presented properly since that's all about the binary content and you shouldn't be sharing that publicly, but you could test the SSL configuration by setting up two brokers (in a test environment) that each have their JMS_X_SITE_CSV_URL pointed at each other. If that configuration gives you EOFExceptions, then switch to using the tcp transport and see what happens. If you get errors with the ssl transport but not the tcp one, there's a good chance it's something wrong with your keys.
As far as the current configuration (where you have a broker whose only networkConnection is a static:ssl: one to itself), it's not a useful configuration (having a networkConnector to yourself serves no purpose), and you proved early on in this discussion that removing it removes the WARN log line that you're concerned about. So I disagree with your statement that "I feel the configuration still seems fine." Either switch to something that serves the purpose you said you're trying to achieve (like the discovery: transport instead of the static: transport, or like listing your cross-site servers if you're going to continue using the static: transport) or take it out and eliminate the WARN line.
So, networkConnector
is essentially of no use if it is a single broker system. Makes more sense in multi-broker deployments and then all the brokers are configured, except the self on each broker separately.
To still make the networkConnector
configuration to work in single broker deployment, the value I had to set was - url="static://(ssl://divinedragonbox:7031)..."
(Hostname instead of IP Address or localhost
). That gets rid of the WARNING
which comes.
Those EOFExceptions indicate a client connects to the broker, then disconnects without cleanly closing the connection. Typical culprits include tcp/ip monitoring agents and incorrectly coded clients.