Hi Barry,
> I'm using Glassfish V3 (and thus Grizzly) as a replacement for Apache.
> Grizzly has left me amazed with Java performance in general and some
> internal tests show very high performance when serving static files.
> (I've yet to compare it with Apache, but I think the comparison will
> be favorable)
>
> One thing I did notice was that while running a benchmark with more
> than 300 concurrent connections will lock up Glassfish due to running
> out of filedescriptors.
> I'm not running anything other than Glassfish V3 / Grizzly at this
> moment and it's serving just 32 unique files.
> One source of potential problems may be here:
> https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/StaticResourcesAdapter.html
> #207
> A new FileChannel is created during the request (which means a file
> descriptor is opened in handling the request, even if the file is
> already opened elsewhere)
Right, we open the file for each request, which means we allocate
filedescriptor, but then we don't forget to close the file, so
descriptor should be released.
> Maybe some form of cache could be used to retain these channel
> references for a short while to prevent re-opening them?
For some usecases, probably, cache could optimize performance. But
under heavy load, when clients request different resources - it could
become a bottleneck. Also I'm not sure, if it's possible to perform
read/write operations on one FileDescriptor from different threads
simultaneously.
So, probably cacheing may optimize performance for some cases, but,
IMHO, the implementation we're having now is not causing any file
descriptor leak.
> This does not fully explain it, but it's a start.
> Are there other locations that filedescriptors are opened?
Yes :)
Actually each network Socket, NIO Selector allocates a file descriptor.
> A temporary workaround would be to increase FD count using ulimit,
> which I've done.
After you increased ulimit and leave the test running for example for
hour or more, do you see the issue? If not - it probably means there
is no leak, if yes - we can continue investigation.
Which app are you using for stress testing?
> BTW, another issue is that no matter what I do it would seem my poor
> Gbit connection is a limiting factor.
:))
Thank you.
WBR,
Alexey.
>
> Regards,
>
> Barry
>
> --
> Barry van Someren
> ---------------------------------------
> LinkedIn: http://www.linkedin.com/in/barryvansomeren
> Skype: BvsomerenSprout
> Blog: http://blog.bvansomeren.com
> KvK: 27317624
> irc: BarryNL @ FreeNode
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>