On Mon, May 21, 2012 at 10:48 AM, Mark Thomas <ma...@apache.org> wrote:
> On 21/05/2012 18:30, Costin Manolache wrote: > > On Mon, May 21, 2012 at 9:29 AM, Mark Thomas <ma...@apache.org> wrote: > > > >> On 21/05/2012 15:26, Costin Manolache wrote: > >>> My understanding is that the timeout is implemented in poll.c > maintain() > >> - > >>> by scanning the socket list in C. > >>> > >>> Why not doing the same thing in java - i.e. don't touch native code, > have > >>> all sockets 'long', and close whenever you need from java ? > >> > >> The timeout is also used in poll so it wouldn't be a completely clean > >> solution. > > > > > > How is it used in poll ? The poll can be arbitrary - there is no need to > > guarantee that sockets timeout at the exact moment, it can happen later. > > If poll time is 1/2 hour - than if no event happens you'll check every > 1/2 > > hour which sockets are expired. > > It is used to ensure that the poll does not last beyond the next > expected time out. While I agree time out can happen later, the current > API isn't written that way and I not happy changing something like that > in a point release. > My point was that you don't need to change anything in native. Leave APR as it is - just use '0' as timeout for the websocket sockets ( or any scoket that needs arbitrary timeout ). That will disable the processing in maintain - and java side can do the expiration. No compilation headaches - the only downside is that the actual expiration may happen a bit later. > > The benefit of doing it in java is that you have more control - and may > use > > more advanced structures ( C is just a loop over the list of sockets, > > wouldn't scale very well to 100K+ sockets - which are probably normal > case > > for websocket ). > > In the WebSocket case, the time out will be in Java. I just need the > ability to set it to infinite without creating yet another PollSet. > While I currently think per socket timeout is the way to go (it will > simplify the current APR/native Poller code) I'm not wedded to the idea. > If this doesn't work, I'm happy to look at alternatives. > What's the problem with creating another PollSet ? The spdy implementation does create one ( AprSocketContext ), doesn't seem so bad. BTW - given the use case for web sockets, i.e. very large number of mostly idle sockets, you may have to create multiple pollsets anyway, don't remember what are the limits on one pollset but you probably don't want to mix 100K idle websockets in the active http pollset. Costin > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
