The JRE never exits when a DirectTransfer receives a "HostId not allowed" error

[bcarlin]

The scenario to reproduce the error is the following :

an R66 client sends a file to an R66 server, which has no entry for the client in its partner database, with a DirectTransfer (I suppose it is the same for other types of transfers).
The client receives an error packet A, closes its network and database connections, but never exits.

I attached the debug logs for such a transfer.

Can it be included in the 3.3.2 version ?

client.log

[fredericBregier]

I try with a client named hostunknown to hostbs. Client knows Hostbs, but Hostbs doesn't know client hostunknown.

Under Linux, the very same scenario (is it?) has no issue.
The client is trying to connect, cannot (being refused by server) and finaly exit with Value 5 (ConnectionImpossible).

See log in file.
client.txt

[fredericBregier]

Of course, the very same client sending to a host that knows about it ends up with correct transfer.

[fredericBregier]

And if we try to send to an unknown host from client, then it stops early with "Cannot find host" and error 21 (Unknown)

[bcarlin]

To clarify things, I created a gist with the config and a script to reproduce it (here)

To use it :

git clone https://gist.github.com/8fd60dc184f9f5bc210c5e48056ac33d.git tmp
cd tmp
./run.sh

(I have the same result with this conf on windows)

[fredericBregier]

I will try again, but I notice that your configuration gives the same IP/PORT to client and host...
Will try to reproduce however... (still not able)

[fredericBregier]

OK I'm able to reproduce...
Strange that my example (almost same) does work...
Investigate

[fredericBregier]

Fix in the v3.3.2. When such a connection was attempted, the related "future" was not set accordingly. Now it is and should be ok for any other cases too that were missing.

Don't get it why my own ewample was not showing this... Of course, such issue can be difficult to test in Junit. So we might keep this kind of tests as "manual test".

[fredericBregier]

You can try with this jar...

WaarpR66-3.3.2-jar-with-dependencies.jar.zip

[bcarlin]

With this jar, the process exits, but on my test instances, it exits after 2m50s (logs attached).
during this time, it does numerous retries (I counted 9 NEW PHYSICAL CONNECTION REQUIRED in the attached logs). BTW: are retries really necessary in case of bad authent ?

client.log

[fredericBregier]

There is no simple way to prevent retry, I think.

[fredericBregier]

Moreover, retry allows the remote host to be updated in its configuration, and therefore that this client being authenticated finally, even during the 9th try. That's the principle of retries and "sleep" in between.
I believe that one option (but it is an evolution, not a fix) could be to have a "fail fast" option, such that in any case of failure, no retry is done. But I don't think it is so useful.

[bcarlin]

Ok.
However, the subsequents retries end with Shutdown Errors :

18:17:44.927 [main] DEBUG org.waarp.common.state.MachineState - org.waarp.common.state.MachineState.setAsFinal(MachineState.java:176) : [server1] New State: AUTHENTR from STARTUP
18:17:44.932 [Handler-8] INFO org.waarp.openr66.protocol.networkhandler.NetworkServerHandler - org.waarp.openr66.protocol.networkhandler.NetworkServerHandler.channelInactive(NetworkServerHandler.java:113) : [server1] Network Channel Closed: 7502a157 LocalChannels Left: 1
18:17:51.618 [Handler-8] DEBUG org.waarp.openr66.protocol.localhandler.LocalChannelReference - org.waarp.openr66.protocol.localhandler.LocalChannelReference.invalidateRequest(LocalChannelReference.java:499) : [server1] FET: false:false FVR: false:false FR: false:false Shutdown order

Which obfuscate the real error HostId not allowed.

The final output is :

{"command":"DirectTransfer","args":"etc/conf.d/server1/client.xml -to server1 -rule default -file foo.txt ","remote":"server1","ruleid":"default","statusCode":"C","specialid":-9223372036854775798,"finalPath":"foo.txt","requested":"server1","requester":"server1","fileInformation":"noinfo","originalSize":6,"originalPath":"foo.txt","status":2,"statusTxt":"Transfer in status:       FAILURE "}

[fredericBregier]

OK, I check again.

I was able to fix this too. Retry is stopped in case of No Authentication (not other cases) and the final status is preserved then.

See update in #16 and in the following jar

WaarpR66-3.3.2-jar-with-dependencies.jar.zip

[bcarlin]

👍
Great! Thank you!