[Geoserver-devel] Shutting down Thread Pools

GeoServer GeoServer Developer
1

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.

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?

···

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

2

On Fri, Jan 23, 2015 at 8:45 PM, Kevin Smith <ksmith@anonymised.com>
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?

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"

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.

-------------------------------------------------------

3

23 January 2015 at 12:35, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Fri, Jan 23, 2015 at 8:45 PM, Kevin Smith <ksmith@anonymised.com>
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/&gt;

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo <http://twitter.com/boundlessgeo/&gt;

<http://twitter.com/boundlessgeo/&gt;

[image: http://boundlessgeo.com/\]
<http://boundlessgeo.com/&gt;

4

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.

Implementing using an internal FileSystemWatcher should be pretty
straightforward since I *did* match the design. I got the impression the
JVM would hook into operating system file change notification (or take care
of polling like we do with a thread pool).
--
Jody

5

On 23 January 2015 at 13:30, Jody Garnett <jody.garnett@anonymised.com> wrote:

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.

Implementing using an internal FileSystemWatcher should be pretty
straightforward since I *did* match the design. I got the impression the
JVM would hook into operating system file change notification (or take care
of polling like we do with a thread pool).
--
Jody

The WatchService is created from a specific FileSystem object where
FileSystemWatcher has no concept of specific file systems. It looks like
maybe a "File System" in Java is a context for file paths (in which case
it's doing pretty much the same thing ResourceStore API does) rather than a
specific OS level file system. The Java documentation just uses the term
without defining it though. I'm a little worried that the dependence on
file systems means the whole thing will break when traversing a mount point
or a symlink to another mounted filesystem.

--

Kevin Smith

Software Engineer | Boundless <http://boundlessgeo.com/&gt;

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo <http://twitter.com/boundlessgeo/&gt;

<http://twitter.com/boundlessgeo/&gt;

[image: http://boundlessgeo.com/\]
<http://boundlessgeo.com/&gt;

6

On 23 January 2015 at 14:17, Kevin Smith <ksmith@anonymised.com> wrote:

On 23 January 2015 at 13:30, Jody Garnett <jody.garnett@anonymised.com> wrote:

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.

Implementing using an internal FileSystemWatcher should be pretty
straightforward since I *did* match the design. I got the impression the
JVM would hook into operating system file change notification (or take care
of polling like we do with a thread pool).
--
Jody

The WatchService is created from a specific FileSystem object where
FileSystemWatcher has no concept of specific file systems. It looks like
maybe a "File System" in Java is a context for file paths (in which case
it's doing pretty much the same thing ResourceStore API does) rather than a
specific OS level file system. The Java documentation just uses the term
without defining it though. I'm a little worried that the dependence on
file systems means the whole thing will break when traversing a mount point
or a symlink to another mounted filesystem.

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)

--

Kevin Smith

Software Engineer | Boundless <http://boundlessgeo.com/&gt;

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo <http://twitter.com/boundlessgeo/&gt;

<http://twitter.com/boundlessgeo/&gt;

[image: http://boundlessgeo.com/\]
<http://boundlessgeo.com/&gt;

7

On Sat, Jan 24, 2015 at 12:02 AM, Kevin Smith <ksmith@anonymised.com>
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.

-------------------------------------------------------

8

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 <andrea.aime@anonymised.com> wrote:

–

On Sat, Jan 24, 2015 at 12:02 AM, Kevin Smith <ksmith@anonymised.com> wrote:

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.

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)

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

9

Can we mark that thread pool as daemon so it won’t hold the JRE open?

···

On 26 January 2015 at 16:14, Kevin Smith <ksmith@anonymised.com> 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.

–
Jody Garnett

On 24 January 2015 at 05:55, Andrea Aime <andrea.aime@anonymised.com.1268…> wrote:

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

On Sat, Jan 24, 2015 at 12:02 AM, Kevin Smith <ksmith@anonymised.com> wrote:

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.

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)

10

Yes, marking the threadpools as Daemon is the really trivial but kludgy way of doing it. The Disposer is the nicer but still a bit of a kludge way which as the benefit of not leaving the threadpools open after doing an undeploy. Making several additional classes Disposable so that they can cascade the disposal properly is the really nice and tidy way that involves a lot of work, and probably can’t be backported.

···

On 26 January 2015 at 16:22, Jody Garnett <jody.garnett@anonymised.com> wrote:

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 <ksmith@anonymised.com> 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 <andrea.aime@anonymised.com> wrote:

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

On Sat, Jan 24, 2015 at 12:02 AM, Kevin Smith <ksmith@anonymised.com> wrote:

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.

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)

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

11

On Tue, Jan 27, 2015 at 1:33 AM, Kevin Smith <ksmith@anonymised.com>
wrote:

Yes, marking the threadpools as Daemon is the really trivial but kludgy
way of doing it. The Disposer is the nicer but still a bit of a kludge way
which as the benefit of not leaving the threadpools open after doing an
undeploy. Making several additional classes Disposable so that they can
cascade the disposal properly is the really nice and tidy way that involves
a lot of work, and probably can't be backported.

I did not look in the details, but the assesment of trying to do clean
disposing being hard feels right.

The Disposer object is indeed a simpler solution, but it might have a
gotcha, what if anything
needs the object being disposed during the shutdown?
Is there any way to make sure the Disposer runs _last_ in the Spring
context shutdown order?
Or anything at the servlet specification level?

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.

-------------------------------------------------------

12

The only mechanism I can see to force ordering of destruction is to make other beans depend on Disposer. Of course anything in a position to mark itself as depending on Disposer doesn’t need Disposer as it could just be a DisposableBean itself and then dispose of its resources properly. We could make a few significant components depend on Disposer to try to shunt it down the list a reasonable distance and then document that once destruction starts, registered objects might be destroyed at any time, and if that’s not good enough then proper disposal should be used instead.

···

On 27 January 2015 at 00:51, Andrea Aime <andrea.aime@anonymised.com…> wrote:

–

On Tue, Jan 27, 2015 at 1:33 AM, Kevin Smith <ksmith@anonymised.com> wrote:

Yes, marking the threadpools as Daemon is the really trivial but kludgy way of doing it. The Disposer is the nicer but still a bit of a kludge way which as the benefit of not leaving the threadpools open after doing an undeploy. Making several additional classes Disposable so that they can cascade the disposal properly is the really nice and tidy way that involves a lot of work, and probably can’t be backported.

I did not look in the details, but the assesment of trying to do clean disposing being hard feels right.

The Disposer object is indeed a simpler solution, but it might have a gotcha, what if anything
needs the object being disposed during the shutdown?
Is there any way to make sure the Disposer runs last in the Spring context shutdown order?
Or anything at the servlet specification level?

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

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

13

As for ordering, it appears that:

“Based on the initialization order of beans, this same order will be followed in reverse for consistency.”

So registering the Disposer first will ensure it gets called last. If relative order is important (as you note, Kevin), components that require ‘late’ disposal can register w/ the Disposer.

···

On Tue, Jan 27, 2015 at 12:47 PM, Kevin Smith <ksmith@anonymised.com> wrote:

The only mechanism I can see to force ordering of destruction is to make other beans depend on Disposer. Of course anything in a position to mark itself as depending on Disposer doesn’t need Disposer as it could just be a DisposableBean itself and then dispose of its resources properly. We could make a few significant components depend on Disposer to try to shunt it down the list a reasonable distance and then document that once destruction starts, registered objects might be destroyed at any time, and if that’s not good enough then proper disposal should be used instead.

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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

On 27 January 2015 at 00:51, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

On Tue, Jan 27, 2015 at 1:33 AM, Kevin Smith <ksmith@anonymised.com> wrote:

Yes, marking the threadpools as Daemon is the really trivial but kludgy way of doing it. The Disposer is the nicer but still a bit of a kludge way which as the benefit of not leaving the threadpools open after doing an undeploy. Making several additional classes Disposable so that they can cascade the disposal properly is the really nice and tidy way that involves a lot of work, and probably can’t be backported.

I did not look in the details, but the assesment of trying to do clean disposing being hard feels right.

The Disposer object is indeed a simpler solution, but it might have a gotcha, what if anything
needs the object being disposed during the shutdown?
Is there any way to make sure the Disposer runs last in the Spring context shutdown order?
Or anything at the servlet specification level?

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.

Ian Schneider
Software Engineer | Boundless
ischneider@anonymised.com
1-877-673-6436

@boundlessgeo

14

Spring doesn’t operate so much on the basis of registering things in an order as looking at the dependencies between bean definitions, then it comes up with an ordering based on that. To get the desired ordering requires that all beans declare that they depend on Disposer. The point of Disposer is to provide something that does work on a ‘register for destruction’ basis, so it might well make sense to have it do that destruction in reverse order of registration.

I’m inclined to go with just making a best effort by having a few major components depend on it, and then document that anything needing guarantees about the order of destruction within the spring context beyond that should be using beans in the spring context rather than Disposer.

···

On 27 January 2015 at 12:03, Ian Schneider <ischneider@anonymised.com> wrote:

As for ordering, it appears that:

“Based on the initialization order of beans, this same order will be followed in reverse for consistency.”

So registering the Disposer first will ensure it gets called last. If relative order is important (as you note, Kevin), components that require ‘late’ disposal can register w/ the Disposer.

–

On Tue, Jan 27, 2015 at 12:47 PM, Kevin Smith <ksmith@anonymised.com> wrote:

The only mechanism I can see to force ordering of destruction is to make other beans depend on Disposer. Of course anything in a position to mark itself as depending on Disposer doesn’t need Disposer as it could just be a DisposableBean itself and then dispose of its resources properly. We could make a few significant components depend on Disposer to try to shunt it down the list a reasonable distance and then document that once destruction starts, registered objects might be destroyed at any time, and if that’s not good enough then proper disposal should be used instead.

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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Ian Schneider
Software Engineer | Boundless
ischneider@anonymised.com
1-877-673-6436

@boundlessgeo

On 27 January 2015 at 00:51, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

On Tue, Jan 27, 2015 at 1:33 AM, Kevin Smith <ksmith@anonymised.com…> wrote:

Yes, marking the threadpools as Daemon is the really trivial but kludgy way of doing it. The Disposer is the nicer but still a bit of a kludge way which as the benefit of not leaving the threadpools open after doing an undeploy. Making several additional classes Disposable so that they can cascade the disposal properly is the really nice and tidy way that involves a lot of work, and probably can’t be backported.

I did not look in the details, but the assesment of trying to do clean disposing being hard feels right.

The Disposer object is indeed a simpler solution, but it might have a gotcha, what if anything
needs the object being disposed during the shutdown?
Is there any way to make sure the Disposer runs last in the Spring context shutdown order?
Or anything at the servlet specification level?

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

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

15

I’d like to get this fixed soon. Does anyone have a problem with documenting the limitations of the Disposer in terms of guaranteeing the order of destruction? Failing that I’ll go with the Daemon thread approach which fixes the immediate problem and is otherwise no worse than the current way things work, and has been used elsewhere.

···

On 29 January 2015 at 11:32, Kevin Smith <ksmith@anonymised.com> wrote:

Spring doesn’t operate so much on the basis of registering things in an order as looking at the dependencies between bean definitions, then it comes up with an ordering based on that. To get the desired ordering requires that all beans declare that they depend on Disposer. The point of Disposer is to provide something that does work on a ‘register for destruction’ basis, so it might well make sense to have it do that destruction in reverse order of registration.

I’m inclined to go with just making a best effort by having a few major components depend on it, and then document that anything needing guarantees about the order of destruction within the spring context beyond that should be using beans in the spring context rather than Disposer.

–

On 27 January 2015 at 12:03, Ian Schneider <ischneider@anonymised.com> wrote:

As for ordering, it appears that:

“Based on the initialization order of beans, this same order will be followed in reverse for consistency.”

So registering the Disposer first will ensure it gets called last. If relative order is important (as you note, Kevin), components that require ‘late’ disposal can register w/ the Disposer.

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

On Tue, Jan 27, 2015 at 12:47 PM, Kevin Smith <ksmith@anonymised.com> wrote:

The only mechanism I can see to force ordering of destruction is to make other beans depend on Disposer. Of course anything in a position to mark itself as depending on Disposer doesn’t need Disposer as it could just be a DisposableBean itself and then dispose of its resources properly. We could make a few significant components depend on Disposer to try to shunt it down the list a reasonable distance and then document that once destruction starts, registered objects might be destroyed at any time, and if that’s not good enough then proper disposal should be used instead.

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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Ian Schneider
Software Engineer | Boundless
ischneider@anonymised.com
1-877-673-6436

@boundlessgeo

On 27 January 2015 at 00:51, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

On Tue, Jan 27, 2015 at 1:33 AM, Kevin Smith <ksmith@anonymised.com> wrote:

Yes, marking the threadpools as Daemon is the really trivial but kludgy way of doing it. The Disposer is the nicer but still a bit of a kludge way which as the benefit of not leaving the threadpools open after doing an undeploy. Making several additional classes Disposable so that they can cascade the disposal properly is the really nice and tidy way that involves a lot of work, and probably can’t be backported.

I did not look in the details, but the assesment of trying to do clean disposing being hard feels right.

The Disposer object is indeed a simpler solution, but it might have a gotcha, what if anything
needs the object being disposed during the shutdown?
Is there any way to make sure the Disposer runs last in the Spring context shutdown order?
Or anything at the servlet specification level?

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

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

16

I would be happy with Disposer.

Please mark the FileWatcher thread pool as Daemon in anywise (as that was my intention when writing).

···

On 4 February 2015 at 12:45, Kevin Smith <ksmith@anonymised.com> wrote:

I’d like to get this fixed soon. Does anyone have a problem with documenting the limitations of the Disposer in terms of guaranteeing the order of destruction? Failing that I’ll go with the Daemon thread approach which fixes the immediate problem and is otherwise no worse than the current way things work, and has been used elsewhere.

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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Jody Garnett

On 29 January 2015 at 11:32, Kevin Smith <ksmith@anonymised.com> wrote:

Spring doesn’t operate so much on the basis of registering things in an order as looking at the dependencies between bean definitions, then it comes up with an ordering based on that. To get the desired ordering requires that all beans declare that they depend on Disposer. The point of Disposer is to provide something that does work on a ‘register for destruction’ basis, so it might well make sense to have it do that destruction in reverse order of registration.

I’m inclined to go with just making a best effort by having a few major components depend on it, and then document that anything needing guarantees about the order of destruction within the spring context beyond that should be using beans in the spring context rather than Disposer.

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

On 27 January 2015 at 12:03, Ian Schneider <ischneider@anonymised.com> wrote:

As for ordering, it appears that:

“Based on the initialization order of beans, this same order will be followed in reverse for consistency.”

So registering the Disposer first will ensure it gets called last. If relative order is important (as you note, Kevin), components that require ‘late’ disposal can register w/ the Disposer.

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

On Tue, Jan 27, 2015 at 12:47 PM, Kevin Smith <ksmith@anonymised.com> wrote:

The only mechanism I can see to force ordering of destruction is to make other beans depend on Disposer. Of course anything in a position to mark itself as depending on Disposer doesn’t need Disposer as it could just be a DisposableBean itself and then dispose of its resources properly. We could make a few significant components depend on Disposer to try to shunt it down the list a reasonable distance and then document that once destruction starts, registered objects might be destroyed at any time, and if that’s not good enough then proper disposal should be used instead.

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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Ian Schneider
Software Engineer | Boundless
ischneider@anonymised.com
1-877-673-6436

@boundlessgeo

On 27 January 2015 at 00:51, Andrea Aime <andrea.aime@anonymised.com.1268…> wrote:

–

Kevin Smith

Software Engineer | Boundless

ksmith@anonymised.com

+1-778-785-7459

@boundlessgeo

http://boundlessgeo.com/

On Tue, Jan 27, 2015 at 1:33 AM, Kevin Smith <ksmith@anonymised.com> wrote:

Yes, marking the threadpools as Daemon is the really trivial but kludgy way of doing it. The Disposer is the nicer but still a bit of a kludge way which as the benefit of not leaving the threadpools open after doing an undeploy. Making several additional classes Disposable so that they can cascade the disposal properly is the really nice and tidy way that involves a lot of work, and probably can’t be backported.

I did not look in the details, but the assesment of trying to do clean disposing being hard feels right.

The Disposer object is indeed a simpler solution, but it might have a gotcha, what if anything
needs the object being disposed during the shutdown?
Is there any way to make sure the Disposer runs last in the Spring context shutdown order?
Or anything at the servlet specification level?

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.

17

Hi Geoserver community,
For every WMS layer that has latLongBoundingBox set up in the config, GeoServer may restrict the request to the configured latLongBoundingBox. At the moment, it doesn't, and this results in unnecessary query and wastes connections and cursors (for Oracle).
Thus I propose to add an option in the code for latLongBoundingBox range checking. the option will allow to filter the none result query which is out of latLongBoundingBox range and improve the performance.
If community reckon that it is the right way, I am willing to submit a code patch to implement it if necessary.
Thanks first,
Lingbo

18

Interesting. I would normally expect the GeoTools datastore to handle this - but you are correct if you can tell up front that there is no data in the provided bounds you could avoid instantiating a datastore completely.

A couple of notes of caution. Lat long bounding box is fairly lax, you may find it more accurate to project the request into the native projection and check against the native bounds.

···

On 4 February 2015 at 20:29, <Lingbo.Jiang@anonymised.com> wrote:

Hi Geoserver community,

For every WMS layer that has latLongBoundingBox set up in the config, GeoServer may restrict the request to the configured latLongBoundingBox. At the moment, it doesn’t, and this results in unnecessary query and wastes connections and cursors (for Oracle).

Thus I propose to add an option in the code for latLongBoundingBox range checking. the option will allow to filter the none result query which is out of latLongBoundingBox range and improve the performance.

If community reckon that it is the right way, I am willing to submit a code patch to implement it if necessary.

Thanks first,

Lingbo

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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Jody Garnett

19

On Thu, Feb 5, 2015 at 5:29 AM, <Lingbo.Jiang@anonymised.com> wrote:

  Hi Geoserver community,

For every WMS layer that has latLongBoundingBox set up in the config,
GeoServer may restrict the request to the configured latLongBoundingBox. At
the moment, it doesn't, and this results in unnecessary query and wastes
connections and cursors (for Oracle).

Thus I propose to add an option in the code for latLongBoundingBox range
checking. the option will allow to filter the none result query which is
out of latLongBoundingBox range and improve the performance.

If community reckon that it is the right way, I am willing to submit a
code patch to implement it if necessary.

I would first understand better how the extra complexity is going to pull
its weight (because we'll have to maintain it,
and explain it to users).
A jdbc reader will open a connection for a very short amount of time, and
in normal situations you'd need to have a
very high load on empty areas to make the optimizations you're talking
about worthwhile... I fully understand there
is going to be a benefit, but is it going to be a 0.1% speedup, 1%, 10%?
If you take for example the usual wms shootout, you'll get almost nothing
out of it because most of the requests
are hitting areas where we have data, and the normal OGC/custom made
clients do the same as they respect the data boundaries
declared in the capabilities document.

Is it maybe related to the design of app-schema, which makes the reader
somehow hold to the connections and
resultsets for a longer time than normal simple feature usage?

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.

-------------------------------------------------------

20

Hi,

I think that such check should be optional. The bounding box that gets saved when the layer is created may not stay valid if the data are updated and new features are added with WFS-T or just directly to the data source. And obviously the check should only stop the queries if BBOX is totally outside the data extents.

I do not know how expensive the out-of-range requests are but I guess that bounding box filter could only make things faster but not any slower. But if you decide to go that way, why to do the test with an inaccurate bounding box? About 50% of the BBOX of Finland is actually Sweden, Russia, Norway, or empty sea. How about making an additional configuration option “Bounding Polygon” and use that? A further development step would be to make the integrated GWC to utilize this Bounding Polygon as well.

-Jukka Rahkonen-

···

Lingbo Jiang wrote:

Hi Geoserver community,

For every WMS layer that has latLongBoundingBox set up in the config, GeoServer may restrict the request to the configured latLongBoundingBox. At the moment, it doesn’t, and this results in unnecessary query and wastes connections and cursors (for Oracle).

Thus I propose to add an option in the code for latLongBoundingBox range checking. the option will allow to filter the none result query which is out of latLongBoundingBox range and improve the performance.

If community reckon that it is the right way, I am willing to submit a code patch to implement it if necessary.

Thanks first,

Lingbo