23 January 2015 at 12:35, Andrea Aime <[email protected]> wrote:
> On Fri, Jan 23, 2015 at 8:45 PM, Kevin Smith <[email protected]>
> wrote:
>
>> I've found two sources of non-daemon thread pools that aren't being shut
>> down properly.
>>
>> https://jira.codehaus.org/browse/GEOS-6850
>>
>> One is in GuavaAuthenticationCacheImpl, the other in FileSystemWatcher
>> used to provide update notification for the FileResourceStore.
>>
>> The simple solution would be to toss in a ThreadFactory to make them
>> daemon threads so they don't hold up VM shutdown.
>>
>> Shutting them down properly though would be preferable.
>> GuavaAuthenticationCache would be fairly simple to make a DisposableBean
>> but FileResourceStore is not.
>>
>
> DisposableBean is the way to go. As for FileSystemWatcher, the javadoc
> says:
>
> " * This implementation currently polls the file system and should be
> updated with Java 7 WatchService when available. The internal design is
> similar
> * to WatchService, WatchKey and WatchEvent in order to facilitate this
> transition."
>
> We are on Java 7 now so... time to upgrade?
>
Yes, I looked at that, unfortunately it needs to be shut down as well. You
have to call the close method on the WatchService when done with it or risk
having it leave threads lying around as well. I'm also not sure enough of
the details of WatchService particularly how it's tied to a specific
"FileSystem" which may complicate implementing FileSystemWatcher in terms
of it.
>
>
>> One thing that comes to mind is adding a method to GeoServerExtension to
>> register a DisposableBean that was not instantiated as a spring bean to be
>> disposed of on context shutdown. Any thoughts on this?
>>
>
> Does not seem the right place, has nothing to do with "extensions"
>
Yes that bothered me but it was the most obvious place that is related to
the context which is easily accessible. A new API which either works like
GeoServerExtensions, or which can be looked up using it could work
instead. Or if there's some callback/registration for cleanup lurking
somewhere I don't know about, that would work too. FileSystemResourceStore
objects are created in a lot of different places so requiring they be
constructed with an ApplicationContext would be a pain, as would changing
their contract to require that they be disposed of or be sent application
context events.
--
Kevin Smith
Software Engineer | Boundless <http://boundlessgeo.com/>
[email protected]
+1-778-785-7459
@boundlessgeo <http://twitter.com/boundlessgeo/>
<http://twitter.com/boundlessgeo/>
[image: http://boundlessgeo.com/]
<http://boundlessgeo.com/>
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel