paho.mqtt.java Already Connected exception on wrong password over websockets

When I attempt to connect with the incorrect password using ws:// or wss:// schemes, I get "Already connected" exception. Using tcp:// or ssl:// results in "Not authorized to connect (5)", as it should be.

I tried this with Paho 1.1.0 and 1.2.0 against Mosquitto and a commercial MQTT broker with the same outcome.

Feb 11 '18 23:02 uvzubovs

Hi @uvzubovs, what MQTT server are you using to test this?

Mar 26 '18 15:03 jpwsutton

I ran into it with Solace, but then reproduced with Mosquitto 1.4.9, which makes me believe it's a library implementation. Here is the stack trace:

MqttException (0) - java.io.IOException: Already connected at org.eclipse.paho.client.mqttv3.internal.ExceptionHelper.createMqttException(ExceptionHelper.java:38) at org.eclipse.paho.client.mqttv3.internal.ClientComms$ConnectBG.run(ClientComms.java:715) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: java.io.IOException: Already connected at java.io.PipedOutputStream.connect(PipedOutputStream.java:100) at java.io.PipedInputStream.connect(PipedInputStream.java:188) at org.eclipse.paho.client.mqttv3.internal.websocket.WebSocketReceiver.<init>(WebSocketReceiver.java:42) at org.eclipse.paho.client.mqttv3.internal.websocket.WebSocketSecureNetworkModule.start(WebSocketSecureNetworkModule.java:64) at org.eclipse.paho.client.mqttv3.internal.ClientComms$ConnectBG.run(ClientComms.java:701) ... 7 more

Mar 30 '18 19:03 uvzubovs

I also ran into this issue. Reproduced with VerneMQ. So it looks like a library implementation issue indeed.