[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-user
Subject:    Re: JIO Connector support in Tomcat 8.5
From:       Amit Pande <Amit.Pande () veritas ! com>
Date:       2017-02-20 16:54:22
Message-ID: 6FF9FBA0-6916-4EC9-9398-A8DBDBC6EE61 () veritas ! com
[Download RAW message or body]

Thanks Chris. We are indeed evaluating if we can leverage traditional reverse-proxy \
based solutions.

However, continued our POC for the custom NIO endpoint. We extended the NioEndpoint \
of Tomcat 8.5.x and overrode the following methods:

1. Bind
2. Unbind
3. UnlockAccept
4. Acceptor 

Intend to use most of the NIO code for poller threads and other start stop logic. One \
issue faced was that "stopLatch" is not accessible outside the NioEndpoint class. \
This stopLatch is initialized during "bind" and used during "stop". But since we \
override bind and don't have access to "stopLatch"we're facing issues while using the \
default NioEndpoint implementation.

Could an enhancement request be filed to make this field protected similar to other \
fields such as pollerThreadCount, acceptorThreadCount?

Reflection seems too hack-ish and don't see any issues with making this field \
protected instead of private.

Appreciate your thoughts.

Thanks,
Amit

On 2/16/17, 11:48 AM, "Christopher Schultz" <chris@christopherschultz.net> wrote:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA256
    
    Amit,
    
    On 2/13/17 8:19 PM, Amit Pande wrote:
    > Thanks for a quick reply.
    > 
    > What does our custom connector do?
    > 
    > Well, we have a server program which is listening on a port which
    > is mandatory to be open/accessible for the outside world. Outside
    > world only talks to this component which in turn hands off (dup
    > system call) the socket to the other processes. Tomcat being one
    > such process.
    > 
    > Our custom connector accepts the handed-off socket and then
    > resumes the normal processing done by Tomcat.
    
    Why not use a more traditional reverse-proxy, which already knows how
    to handle these kinds of protocols?
    
    > Now for NIO connector, seems we need to have a custom
    > implementation of the SocketChannel but not sure how it might
    > work.
    
    - -chris
    -----BEGIN PGP SIGNATURE-----
    Comment: GPGTools - http://gpgtools.org
    Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
    
    iQIcBAEBCAAGBQJYpeXnAAoJEBzwKT+lPKRY7bQQAKCiCfsy0HZLqRn3qY42IU3E
    Ab49WJTzbblJJAUF+ryn9jrjEOP/3m/a69r+2qotL2bv5L9qY1TBqNjyNgAzQ3b/
    v/WAlDmzV51UUc6vG/1GcHgExgUMAHTLwQ0tvUIBAdcrMiX6EPE3J4/G0Q9T0eSb
    n6ap/WyL0AAPHrx13/xWQeVd1BByrqLiv6DA3+5VbbqewxBbGLUgL1gy/6DNSnCs
    lyTlTOqAnW8vN6vEpHW+7lDYgO1vgRwcfN2aZUzWFf8CSgHKhaG+zVOGWv67pbUy
    sZVmGpgc/v3Xny/sCrKxPTN2LeRIJRbkxffcgSThAmfCCKqswcpKK0XDAhwgVq5+
    EXuz0DQ7LC5e85iIo38wZD7OSft5lf0Gp5UViLzys5WVBkaxdI7Gx/0HPPMJA4d3
    681FilJm3hbd7ngXLX7is5ptnfIKgXgSrWotYjzZMTDHaWX6jvn8ygptXzOXHnJk
    Dz29gSUJ7Ciuxv39IS8vWNaZYmNx73nc3bCO+xRjoBzOzylznAw1wtzdH+kXvayY
    VINusuGur5NlyHERm4/NMQy+T0JSLYvMysEB5UWsUJR4LiAYAMPkNbgiG2sAW7MX
    EJwHQSPCySukb9ileiBI39HzX16cGpIn3RUpiCKzdBpRzKUtmXge5/48WeqCY5UG
    M7WwfZGBqtPeJUqfOybg
    =eMgR
    -----END PGP SIGNATURE-----
    
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
    For additional commands, e-mail: users-help@tomcat.apache.org
    
    


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]