Hi Oleg,

Thanks again for your help.

On Sun, Feb 4, 2018 at 10:16 PM, Oleg Nenashev <o.v.nenas...@gmail.com> wrote:
>
> Hmm... I am concerned about the Blocking IO (BIO) network layer being used by 
> your client. This mode is generally not recommended for production use, 
> timeouts in the classloader may happen.
>
> Selection of BIO may happen if the socket does not get initialized properly 
> (Socket#getChannel() returns null):
> https://github.com/jenkinsci/remoting/blob/cd81fcf98ad7af7059703b9150e87f81fdc3aaf2/src/main/java/org/jenkinsci/remoting/engine/JnlpProtocol4Handler.java#L190-L200
>

I wasn't aware that the BIONetworkLayer was not recommended for production use.

I ran the Swarm Client under a debugger and saw that BIONetworkLayer
is chosen over NIONetworkLayer because the isPreferNio() method
returns false on line 192 of the file you linked to above.
isPreferNio(), in turn, returns the value of a boolean field which is
set by the constructor. I put a breakpoint on the constructor and saw
that it's initialized from this stack:

JnlpProtocol4Handler(JnlpProtocolHandler<STATE>).<init>(JnlpClientDatabase,
boolean) line: 63
JnlpProtocol4Handler.<init>(JnlpClientDatabase, ExecutorService,
IOHub, SSLContext, boolean, boolean) line: 107
JnlpProtocolHandlerFactory.handlers() line: 166
Engine.innerRun(IOHub, SSLContext, ExecutorService) line: 485
Engine.run() line: 469

The interesting part of this stack is the innerRun method, which is
where we set preferNio to false:

    private void innerRun(IOHub hub, SSLContext context,
ExecutorService service) {
        // Create the protocols that will be attempted to connect to the master.
        List<JnlpProtocolHandler> protocols = new
JnlpProtocolHandlerFactory(service)
                .withIOHub(hub)
                .withSSLContext(context)
                .withPreferNonBlockingIO(false) // we only have one
connection, prefer blocking I/O
                .handlers();

As you can see, here we explicitly set preferNio to false when
initializing JnlpProtocol4Handler. Why would we do this if blocking
I/O is "generally not recommended for production use" as you stated
earlier? The comment states: "we only have one connection, prefer
blocking I/O", but I'm not sure I understand the meaning of this
statement.

Thanks,
Basil

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjobaBBhAVT9K3sZa3ZNHpL2VRCesnEMtTYKN4-1%3DZs_XQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to