Hi Justin, answers inline.
Am Dienstag, dem 02.08.2022 um 17:15 -0500 schrieb Justin Bertram: > The needClientAuth parameter is only for an *acceptor* as noted in > the > documentation you cited [1]. Therefore, you can omit this from your > URL. I figured that out myself, docs are a little bit hard to read sometimes with the mix of client + server configuration options mixed. > > The keyStorePath and keyStorePassword are only needed when you're > doing > 2-way SSL. Are you doing 2-way SSL? Is that what you're referring to > when > you say "client auth stuff"? Yes, 2-way SSL is also called http client authentication, look e.g. https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslverifyclient - so if you call it 2-way SSL, we do mean the very same thing here. > > The URL doesn't include httpEnabled=true. The client won't know to > use HTTP > unless you tell it to so this parameter is necessary. The > documentation is > ambiguous on this point. When it says this parameter is no longer > needed it > means it is no longer needed on the *acceptor* configured in > broker.xml. The doc could need an update in that case - how should the reader know that the described magic is only for the acceptor part if connector / acceptor are not mentioned anywhere. > > I'm actually not sure how the client will function with an HTTP > proxy. My expectation here is - if it speaks http it should work with any http proxy - although that's why I am here because it is not working (yet) which may or may not be my fault / but I am out of ideas so input is appreciated. But what is so special in the client about http that needs to be thought of at the proxy if you say the client may not work with a proxy (just asking because if it is just http (1.1) it should work with a proxy - shouldn't it)? > I > don't believe that's something we test, and I can't recall any other > users > with such a configuration. Is there a specific reason you need this > proxy? IT does demand for http(s) traffic to use the proxy which also does the TLS/SSL offloading with 2-way SSL - all common http clients I've tried (e.g. curl, wget, Apache HttpComponents, Javas own http implementation) are working fine with that proxy in place and 2-way SSL but I can't get artemis with netty http working here - but the docs are not very talkative about http support in general - so here we are ;). > Using the client over HTTP will work, but it's not ideal. It's ok if it is not ideal - but I am already failing at the "http will work" part ;). I removed the needClientAuth part and added httpEnabled=true and on the proxy side I'll do have at least some http requests answered with 200 instead 400: 172.23.0.1 - - [03/Aug/2022:08:40:14 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 - 172.23.0.1 - - [03/Aug/2022:08:40:29 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 21 172.23.0.1 - - [03/Aug/2022:08:40:29 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 21 172.23.0.1 - - [03/Aug/2022:08:40:29 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 73 172.23.0.1 - - [03/Aug/2022:08:40:59 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 - 172.23.0.1 - - [03/Aug/2022:08:41:14 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 21 172.23.0.1 - - [03/Aug/2022:08:41:14 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 73 172.23.0.1 - - [03/Aug/2022:08:41:14 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 21 172.23.0.1 - - [03/Aug/2022:08:41:44 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 - 172.23.0.1 - - [03/Aug/2022:08:41:59 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 21 172.23.0.1 - - [03/Aug/2022:08:41:59 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 73 172.23.0.1 - - [03/Aug/2022:08:41:59 +0000] "POST http://localhost:8890/messaging/ActiveMQServlet HTTP/1.1" 200 21 but on the client side which causes the above requests I'll still get this after 30 seconds: Caused by: javax.jms.JMSException: AMQ219014: Timed out after waiting 30,000 ms for response when sending packet -18 at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:539) at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:443) at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:306) at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:254) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionChannel(ClientSessionFactoryImpl.java:1437) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:743) at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:324) at org.apache.activemq.artemis.jms.client.ActiveMQConnection.authorize(ActiveMQConnection.java:661) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:916) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:299) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:294) where it is failing to do this call: // channel1 reference here has to go away response = (CreateSessionResponseMessage) getChannel1().sendBlocking(request, PacketImpl.CREATESESSION_RESP); So it seems to me it is going to get a connection (because there is no SSL handshake error etc. and we see requests answered with http 200) but still something is not working as expected because it is unable to create a session. Ideas? Torsten --
