Can we mark that thread pool as daemon so it won't hold the JRE open?
--
Jody Garnett
On 26 January 2015 at 16:14, Kevin Smith <[email protected]> wrote:
> Yes the problem here is that FileSytemResourceStores are being created in
> multiple places, often in classes that don't require disposal themselves,
> and in some cases are being returned or set as just ResourceStores. I
> can't see a way to reliably handle this by cascading disposals without
> changing a bunch of class contracts to require their disposal.
>
> Adding a Disposer to register objects for disposal certainly isn't
> elegant, but it does allow for making FileSytemResourceStore a
> DisposableBean in a way that avoids API/contract changes to the classes
> that instantiate FileSytemResourceStores. I'd certainly want to
> semi-deprecate the Disposer with a warning that disposing of objects
> properly via Spring context, try-with-reources, etc is preferable to using
> it. Since this is a bug, I'd really like to ensure it's backportable.
>
> It might also work to replace the public constructors for
> FileSystemResourceStore with a factory which registers them for disposal,
> but that would really just be a one off version of the same idea.
>
> On 24 January 2015 at 05:55, Andrea Aime <[email protected]>
> wrote:
>
>> On Sat, Jan 24, 2015 at 12:02 AM, Kevin Smith <[email protected]>
>> wrote:
>>>
>>> I talked to Jody and it looks like this isn't an issue.
>>>
>>> The remaining issue is how to best go about shutting things down
>>> safely. Maybe use a "Disposer" object, DisposableBean objects can be
>>> registered with it and when the context shuts down it destroys them all.
>>> Anything that needs to arrange to have something it created cleaned up can
>>> then grab the Disposer from GeoServerExtensions (still not ideal but it's
>>> been used this way plenty of times before)
>>>
>>
>> I'm wondering... this is not really the first type of object not owned by
>> the spring context, that needs eventual disposing, we have lots, data
>> stores, feature readers,
>> coverage readers, input/output streams, all of them have a
>> dispose()/close() method that needs to be called in order to fully release
>> them.
>>
>> Everything is eventually traced to either the lifespan of a request,
>> where you have the code involved cleaning before the request ends, or the
>> sprint context (e.g., ResourcePool) where the object linked into the
>> spring context cascades the dispose/close calls around.
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/NWWaa2 for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via Poggio alle Viti 1187
>> 55054 Massarosa (LU)
>> Italy
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39 339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>
>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>> principi dettati dal D.Lgs. 196/2003.
>>
>>
>>
>> The information in this message and/or attachments, is intended solely
>> for the attention and use of the named addressee(s) and may be confidential
>> or proprietary in nature or covered by the provisions of privacy act
>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>> Code).Any use not in accord with its purpose, any disclosure, reproduction,
>> copying, distribution, or either dissemination, either whole or partial, is
>> strictly forbidden except previous formal approval of the named
>> addressee(s). If you are not the intended recipient, please contact
>> immediately the sender by telephone, fax or e-mail and delete the
>> information in this message that has been received in error. The sender
>> does not give any warranty or accept liability as the content, accuracy or
>> completeness of sent messages and accepts no responsibility for changes
>> made after they were sent or for other risks which arise as a result of
>> e-mail transmission, viruses, etc.
>>
>> -------------------------------------------------------
>>
>
>
>
> --
>
> 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/>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
