You are. As Mike said below, the previous version of NiFi didn’t support SSL connections to PublishAMQP, so if the connection was working before, it was going over plaintext. Your RabbitMQ server may accept both plain and SSL connections, or it may only support plain.
The bad header error message you posted below does look similar to this reported issue where someone was attempting to connect to RabbitMQ with SSL but the server was only configured to accept plain connections [1]. I would follow Mike’s advice to try without an SSLContextService configured and see if that resolves your issue. Then I would strongly recommend configuring RabbitMQ to use SSL and add the context service back into your configuration. [1] http://stackoverflow.com/a/26391930/70465 <http://stackoverflow.com/a/26391930/70465> Andy LoPresto alopre...@apache.org alopresto.apa...@gmail.com PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Mar 20, 2017, at 1:39 PM, James McMahon <jsmcmah...@gmail.com> wrote: > > Andy, if I set SSLContextService in a PublishAMQP processor, aren't I telling > that processor to specifically use the service to set up an encoded > communication path and to authenticate between my nifi instance and my AMQP > broker - in this case, RabbitMQ? Thank you for following up. -Jim > > On Mon, Mar 20, 2017 at 4:25 PM, Andy LoPresto <alopre...@apache.org > <mailto:alopre...@apache.org>> wrote: > To expand on your earlier question about SSLContextService and client auth > required, the context service will enable if the keystore and/or truststore > are present (the path is valid) and the password provided for each is > correct. It does not attempt to make an external connection to verify that > the certificates will be accepted (at the time of creation, the context > service is not aware of what external resources it will be used to access). > This explains why the service can be enabled but a remote resource still may > not accept the provided certificates. > > > Andy LoPresto > alopre...@apache.org <mailto:alopre...@apache.org> > alopresto.apa...@gmail.com <mailto:alopresto.apa...@gmail.com> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >> On Mar 20, 2017, at 1:16 PM, James McMahon <jsmcmah...@gmail.com >> <mailto:jsmcmah...@gmail.com>> wrote: >> >> Will do. Thank you Mike and Oleg. I will try this approach this evening. -Jim >> >> On Mon, Mar 20, 2017 at 2:21 PM, Michael Moser <moser...@gmail.com >> <mailto:moser...@gmail.com>> wrote: >> James, >> >> Try leaving your PublishAMQP "SSL Context Service" property blank. >> >> In NiFi 0.6.x, PublishAMQP did not support SSL connections. If that NiFi >> version was working for you, then you should not use the SSL properties of >> PublishAMQP in NiFi 0.7.x. The "bad header" message may be RabbitMQ failing >> to understand SSL handshake messages. >> >> -- Mike >> >> >> On Mon, Mar 20, 2017 at 1:24 PM, Oleg Zhurakousky >> <ozhurakou...@hortonworks.com <mailto:ozhurakou...@hortonworks.com>> wrote: >> James >> >> My availability this week is somewhat intermittent, but I will try to dig >> deeper later on >> >> Sent from my iPhone >> >> On Mar 20, 2017, at 19:11, James McMahon <jsmcmah...@gmail.com >> <mailto:jsmcmah...@gmail.com>> wrote: >> >>> My situation appears to be different from this one. There is no bad header >>> error message exhibited in their case, and it's definitely there every time >>> in mine. Additionally, it appears that I do indeed already have a non-Guest >>> user with configure/write/read privileges. >>> >>> That bad header notification may be key, but I cannot determine why that is >>> being triggered with my upgraded version of NiFi. >>> >>> On Mon, Mar 20, 2017 at 12:14 PM, Oleg Zhurakousky >>> <ozhurakou...@hortonworks.com <mailto:ozhurakou...@hortonworks.com>> wrote: >>> James >>> >>> Basically my next question would be if admin-wise the new user had been >>> given the correct permissions as I believe you are experiencing the >>> symptoms described in the following thread >>> http://stackoverflow.com/questions/26811924/spring-amqp-rabbitmq-3-3-5-access-refused-login-was-refused-using-authentica >>> >>> <http://stackoverflow.com/questions/26811924/spring-amqp-rabbitmq-3-3-5-access-refused-login-was-refused-using-authentica> >>> >>> Let me know >>> Oleg >>> >>>> On Mar 20, 2017, at 12:02 PM, James McMahon <jsmcmah...@gmail.com >>>> <mailto:jsmcmah...@gmail.com>> wrote: >>>> >>>> Hi Oleg. The RabbitMQ version is unchanged. I created a user called test, >>>> with its own password. I endeavor to connect as that user from >>>> PublishAMQP. Thanks very much for looking more closely at this. -Jim >>>> >>>> On Mon, Mar 20, 2017 at 11:55 AM, Oleg Zhurakousky >>>> <ozhurakou...@hortonworks.com <mailto:ozhurakou...@hortonworks.com>> wrote: >>>> James, while I am looking couple of questions. >>>> 1. Did you actual RabbitMQ version has changed since you used NiFi 0.6? >>>> 2. Are you using default guest/guest user/password to connect? >>>> >>>> Cheers >>>> Oleg >>>> >>>>> On Mar 20, 2017, at 11:04 AM, James McMahon <jsmcmah...@gmail.com >>>>> <mailto:jsmcmah...@gmail.com>> wrote: >>>>> >>>>> I can certainly share germane pieces from it, Oleg. >>>>> >>>>> Background: NiFi version is 0.7.1. RabbitMQ is 3.6.6. Erlang is 17.5-1. >>>>> >>>>> From nifi-app.log: >>>>> java.lang.IllegalStateException: Failed to establish connection with AMQP >>>>> Broker: com.rabbitmq.client.ConnectionFactory@78...... >>>>> . >>>>> . lots of stack trace lines >>>>> . >>>>> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111] >>>>> Caused by: com.rabbitmq.client.Authentication.FailureException: ACCESS >>>>> REFUSED - Login was refused using authentication PLAIN. For details see >>>>> the broker logfile. >>>>> >>>>> From the rmq log file: >>>>> accepting AMQP connection <0.13753.9> (127.0.0.1:54318 >>>>> <http://127.0.0.1:54318/> -> 127.0.0.1:5673 <http://127.0.0.1:5673/>) >>>>> >>>>> =ERROR REPORT==== 20-Mar-2017:10:46:30 === >>>>> closing AMQP connection <0.20511.61> (127.0.0.1:48902 >>>>> <http://127.0.0.1:48902/> -> 127.0.0.1:5673 <http://127.0.0.1:5673/>): >>>>> {bad header,<< 22,3,3,0,195,1,0,0>>} >>>>> >>>>> I had recently upgraded my NiFi from 0.6.x to 0.7.1. My broker log shows >>>>> successful connections without the error report when I was still 0.6.x. >>>>> Since I upgraded I have not been able to connect with success. >>>>> >>>>> Thanks in advance for your help. I am very interested in why I seem to be >>>>> getting this bad header message now. -Jim >>>>> >>>>> On Mon, Mar 20, 2017 at 10:00 AM, Oleg Zhurakousky >>>>> <ozhurakou...@hortonworks.com <mailto:ozhurakou...@hortonworks.com>> >>>>> wrote: >>>>> James, any chance you can provide stack trace from the logs? >>>>> >>>>> Cheers >>>>> Oleg >>>>> >>>>> > On Mar 20, 2017, at 15:34, James McMahon <jsmcmah...@gmail.com >>>>> > <mailto:jsmcmah...@gmail.com>> wrote: >>>>> > >>>>> > Good morning. I am using a NiFi 0.7 code base. I recently upgraded to >>>>> > that from a 0.6.x version. I'm limited to that 0.7.x baseline now. I >>>>> > realize it is old(er), but I have no choice in the matter. >>>>> > >>>>> > I had a PublishAMQP processor that had been working without issue to >>>>> > connect to RabbitMQ but is now failing with this error: >>>>> > >>>>> > Failed to establish connection with AMQP Broker: >>>>> > com.rabbitmq.client.ConnectionFactory@45cd2c16 >>>>> > >>>>> > I can determine why this is now happening. RabbitMQ appears to be >>>>> > started and running fine. I'm connecting to host localhost, and a >>>>> > specific port that seems available. I get the same error if I >>>>> > (temporarily) turn off my firewall entirely. >>>>> > >>>>> > I am attempting to employ a StandardSSLContextService that Enables >>>>> > without error. >>>>> > >>>>> > How can I troubleshoot this error and figure out why I cannot connect >>>>> > to rabbitMQ using PublishAMQP? Thanks in advance for any help you can >>>>> > offer. -Jim >>>>> >>>> >>>> >>> >>> >> >> > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
