No JNDI Timeout when connecting to incorrect port

[Chad12]

Does anyone know if there is a way to get the SwiftMQ JNDI provider client to properly timeout if it connects to a port which is in fact invalid (but open/listening and accepting connections)? I never get the NamingException I expect to get...

If you take, for example, the standard cli.bat or cli.sh and tell it to connect to a valid open port, but one which is speaking the wrong language; e.g. some web server on port 80 or the sys$routing listener port you should see this behaviour.

It seems to just reconnect repeatedly forever; regardless of the timeout value or maxretries I set as part of the smqp URL? If I point it at the sys$routing port, I can see in SwiftMQ's logs that it isreconnecting every 10 seconds forever.

I get the same behaviour regardless of whether I use cli.bat or try to get a connection programmatically; with either 7.4 or 7.5 jars.

[IIT Software]

Add ";debug=true" to the provider URL to see what's going on. I don't remember that we did test to connect to an invalid port so there might be unexpected results.

[Chad12]

I've tried that, but get no output. :-( It's as if the parameters aren't getting read at all by that point in the processing, as nothing I change in the URI affects the frequency or number of retries.

C:\dev\SWIFTM~2\scripts\win32>java -cp ../../jars/swiftmq.jar;../../jars/jline.jar;../../jars/jndi.jar;../../jars/jms.jar;../../jars/jsse.jar;../../jars/jnet.jar;../../jars/jcert.j
ar com.swiftmq.admin.cli.CLI smqp://localhost:4107/timeout=5000;debug=true QueueConnectionFactory

(where 4107 is the port sys$routing is listening on)

[IIT Software]

We need to test & fix it. I've created a job for this.

[Chad12]

Ahh, okay, thanks for that.

[Leos Bitto]

FYI: if you use swiftmq.jar from 7.5.1 on the client side to connect to an older router version 6.2.1, the client will get blocked when doing the JNDI lookup, too.

[IIT Software]

A higher versioned client can't connect to a lower versioned router, except it connects with the router's (or lower) version. Look here (last version is 750 - we need to update that page).

The problem is within transparent reconnect. Client get's an invalid version during connect and tries to reconnect 50 (default) times. We need to handle this invalid version to avoid entering the reconnect loop.

[Leos Bitto]

I know about the versioning restrictions. However, I could imagine a better solution for a situation when a higher versioned client connects (by mistake) to a lower versioned server than blocking a client thread forever...

[IIT Software]

Yes, that's what I meant. We need to handle that by don't entering the reconnect loop in that case. Will be part of the next release.

[Leos Bitto]

I have tried to connect with a 7.5.3 client to the 6.2.1 server and the result was fine: "NamingException: com.swiftmq.jndi.StopRetryException: Invalid version: 750, connection rejected!". However, when I have used -Dswiftmq.smqp.version=630 with this setup, the client thread still got blocked instead of throwing an exception - I would expect something like "Invalid version: 630, connection rejected!" instead.

[IIT Software]

The fix is only in the 750 protocol stack, not within lower versions.