Print

[drsky]

Hi guys,

Yesterday I was fighting with version 3.2.1 and secured connection.

In tested scenario I have downloaded both driver and node to some host, unpacked to separate directories and manually started out-of-the box setups (without SSL). It worked as expected.

Things have changed when I tried to enable SSL. For this reason I had activated secure connection on node (BTW: how to set server's port on node?). As a result node's was trying to connect, and on server log's I receive such info (after enabling DEBUG):

2013-01-24 07:22:02,397 [DEBUG][org.jppf.server.nio.PlainNioObject.read(96)]: read 4 bytes from input source, count/size = 4/4
2013-01-24 07:22:02,397 [DEBUG][org.jppf.server.nio.PlainNioObject.read(99)]: count = 4, size = 4
2013-01-24 07:22:02,397 [DEBUG][org.jppf.server.nio.acceptor.IdentifyingPeerState.performTransition(73)]: read identifier 'UNKNOWN' for SelectionKeyWrapper[id=17, localhost:43772, readyOps=1, keyOps=0, context=AcceptorContext[channel=SelectionKeyWrapper[id=17], state=IDENTIFYING_PEER, uuid=null, connectionUuid=null, peer=false]]
2013-01-24 07:22:02,398 [DEBUG][org.jppf.server.nio.StateTransitionTask.run(92)]: error on channel SelectionKeyWrapper[id=17, localhost:43772, readyOps=1, keyOps=0, context=AcceptorContext[channel=SelectionKeyWrapper[id=17], state=IDENTIFYING_PEER, uuid=null, connectionUuid=null, peer=false]] : org.jppf.JPPFException: unknown JPPF identifier: -2144403197
org.jppf.JPPFException: unknown JPPF identifier: -2144403197
        at org.jppf.server.nio.acceptor.IdentifyingPeerState.performTransition(IdentifyingPeerState.java:90)
        at org.jppf.server.nio.acceptor.IdentifyingPeerState.performTransition(IdentifyingPeerState.java:33)
        at org.jppf.server.nio.StateTransitionTask.run(StateTransitionTask.java:82)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)

this seems to be really exceptional

The same procedure applied to version 3.1.4 works like a charm.

To clarify described scenario:
 - JRE 1.6 64-bit on Linux Debian 6 was used,
 - standard (demo) certificates were used.

Any ideas?

[lolo]

Hello,

From your description, it seems possible that your node is in SSL mode but trying to connect to the non-secure port of the driver.
Can you check that in the node's configuration you have set "jppf.server.port = x", where x is the server port, and that in the driver you have "jppf.ssl.server.port = x" ?
The same property is used in the node for SSL and non-SSL connections, since the node cannot be in both modes as once.

Also, could you look into the node's log file, I think you should have some kind of SSL handshake exception in it.

Thanks,
-Laurent

[drsky]

Hi,

I am 100% sure that connections are configured ok. The same procedure described above gave exactly the same result also in 3.2 version.

Console output from server follows:

# ./startDriver.sh
driver process id: 18407
management initialized and listening on port 11198
ClientClassServer initialized
NodeClassServer initialized
ClientJobServer initialized
NodeJobServer initialized
Acceptor initialized
-  accepting plain connections on port 11111
- accepting secure connections on port 11443
JPPF Driver initialization complete

And from the node:

> ./startNode.sh
node process id: 18504
Attempting connection to the class server at 10.129.50.1:11443
Attempting connection to the class server at 10.129.50.1:11443
Attempting connection to the class server at 10.129.50.1:11443
^C


Funniest thing happens on node I did the following things:

• jppf.discovery.enabled = false
• jppf.server.port = 11443
• #jppf.ssl.enabled = false

So literally I have disabled disovery and manually forced to enable non-ssl connecition to server's secured port. Result:

> ./startNode.sh
node process id: 18853
Attempting connection to the class server at localhost:11443
Reconnected to the class server
JPPF Node management initialized
Attempting connection to the node server at localhost:11443
Reconnected to the node server
Node successfully initialized

So it means that 11443 on server doesn't handle SSL connection, IMHO. In failure scenario node tries to setup SSL connection to server listening on 11443 with plain connection and it tries to interpret incoming values as JPPF protocol (which obiously fails). Plain node's connection to driver's port 11443 works (which should not happen)...

Thanks,
Adam

[lolo]

Hi Adam,

Thanks a lot for this information. I can indeed reproduce the same behavior and I registered a critical bug report for this: JPPF-120 (Regression) Impossible to make an SSL connection to the server .

I am working on a fix and will deliver a new maintenance release or a patch as soon as a fix is available. I'll keep you updated in this forum thread.

Sincerely,
-Laurent

[lolo]

Hello,

We have fixed this issue and published a new maintenance release JPPF v3.2.2 which includes the fix.

SIncerely

[drsky]

Laurent,

thanks a lot for the info!

Cheers,
Adam