Hello,
>>> 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.
>
> I don't believe Barry was complaining about a possible fd leak, but
> rather about how heavy GF leans on the number of fd's available.
Yep, I understand that know, just wanted to make sure :)
> This means that for high-volume sites with lots of static content,
> GF needs more fd's than another app server might need. Personally I
> believe this is a documentation issue, rather than a bug of any
> kind. The documentation of GF might advise raising the fd's, or at
> least explain the relevant errors messages.
I just thought, that if we open and then close file - we don't need
any extra filedescriptors number. Glassfish, by default, has 5 worker
threads, which means 5 files could be processed simultaneously by
static handler (these are default numbers for sure).
That's why I started to think about some fd leak.
>
> That said, perhaps GF could eek out more performance by reusing
> resources that are open anyway. I doubt a lock-free hashmap of sorts
> to cache the open files in would hurt much. The overhead would be in
> the order of a check and possible an add/remove operation on that
> cache-map.
Actually Grizzly has a cache implementation, though it doesn't cache
fds, but file content itself. Probably it's what you and Barry were
interested in. Seems Glassfish v3 doesn't use it by default. I'll
check this and let you know how you can enable it.
> Without measurements of the effect on the performance when reusing
> such resources we cannot tell either way, though. Barry thinks it
> might help, you dismiss it. I prefer to wait until someone sat down
> and actually measured it.
100% agree :)
Thank you.
WBR,
Alexey.
>
> So.... Anybody with a little spare time? :-)
> --
> Kees Jan
>
> http://java-monitor.com/
> kjkoster_at_kjkoster.org
> 06-51838192
>
> The secret of success lies in the stability of the goal. -- Benjamin
> Disraeli
>