On 20/05/2012 19:44, Henri Gomez wrote: > Did there is a need to have sockets with differents timeout in day to day > case ?
So far, no. The requirements could be met by three pollsets. One for new connections, one for keep-alive connections and one for WebSocket connections. My concern is that this approach is not sustainable. I don't yet know what requirements may emerge from the Servlet 3.1 or WebSocket EGs. Even if no new requirements emerge, a per socket time out would be simpler to work with, consistent with BIO and NIO and may allow for further refactoring to deduplicate code. This is based on my current understanding of the native code which is that adding a per socket time out is relatively simple. I could be wrong. If I am wrong, three pollsets is my fall back plan. Mark > > For example did it is required by specs or API ? > > The finer, the better but only if there is a real need :-) > > Btw, i'll take a look to your commits. > > Le 20 mai 2012 à 20:37, Mark Thomas <ma...@apache.org> a écrit : > >> Currently, time outs for APR/native sockets are managed at the Pollset >> level. This means all sockets in a single Pollset must have the same >> time out. This is starting to become a nuisance. >> >> I have already had to add a second Pollset to AprEndpoint to handle >> separate connection and keep-alive time outs. Now I need to be able to >> handle infinite time outs for WebSocket and I do not want to have to add >> a third Pollset. >> >> Therefore, I intend modifying the APR/native code to support per socket >> time outs. I would be grateful if those of you with more C knowledge >> than I (which is most people on this list) could: >> a) tell me now if this is a crazy idea (and why) >> b) keep an extra close eye on any commit of mine that touches the C code. >> >> I intend to retain backwards compatibility so newer versions of the >> native connector will work with older Tomcat versions but Tomcat 7 will >> have a new minimum native version so that this feature is available. >> This means that the next Tomcat 7 release is likely to have to wait for >> the next native release. >> >> Looking at the code so far, I am likely to start with some renaming to >> clarify the current code before actually changing anything functional. >> >> Mark >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
