Hi,
in GeoServer WPS we are using thread pools to manage the executions of the processes,
both direct calls and asynch ones are executed in their own thread pool to ensure
on one side resource control, on the other aysnch execution.
One of the troubles with the usage of thread pools is that they break thread locals,
some of which are pretty significant, such as the security ones (authentication),
but I’m also thinking about Dispatcher.RESPONSE, and others could be significant
as well.
In order for the WPS processes (and the catalog itself) to access said thread locals
we need to transfer them somehow into the other thread, and then clean them up.
Given this might serve a variety of purposes, I was thinking about an extension point
that would act in three stages:
- collect the thread local from the main thread, store it in some container
- once entered the pool’s thread, get it from the container and set it as a thread local in
the current thread
- once done clean up the thread local
How about something like:
interface ThreadLocalsTransferCallback {
/**
- Collects the current thread locals values into the storage
/
void collect(Map storage);
/*
- Set the thread local values in the current thread
/
void apply(Map storage);
/*
- Clean up the thread locals
*/
void cleanup();
}
The WPS code would then be extended to collect and use the callbacks in
ProcessCallable.
What do you think?
Cheers
Andrea
–
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
(bump… as I’m afraid this one got lost in the Hudson restore mail storm)
On Mon, Feb 18, 2013 at 1:35 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
in GeoServer WPS we are using thread pools to manage the executions of the processes,
both direct calls and asynch ones are executed in their own thread pool to ensure
on one side resource control, on the other aysnch execution.
One of the troubles with the usage of thread pools is that they break thread locals,
some of which are pretty significant, such as the security ones (authentication),
but I’m also thinking about Dispatcher.RESPONSE, and others could be significant
as well.
In order for the WPS processes (and the catalog itself) to access said thread locals
we need to transfer them somehow into the other thread, and then clean them up.
Given this might serve a variety of purposes, I was thinking about an extension point
that would act in three stages:
- collect the thread local from the main thread, store it in some container
- once entered the pool’s thread, get it from the container and set it as a thread local in
the current thread
- once done clean up the thread local
How about something like:
interface ThreadLocalsTransferCallback {
/**
- Collects the current thread locals values into the storage
/
void collect(Map storage);
/*
- Set the thread local values in the current thread
/
void apply(Map storage);
/*
- Clean up the thread locals
*/
void cleanup();
}
The WPS code would then be extended to collect and use the callbacks in
ProcessCallable.
What do you think?
Cheers
Andrea
–
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
–
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
Makes sense. So if I understand it an implementation of one of these interfaces would accompany every thread local we use?
I wonder if we could get away without an extension point, but rather just a utility class that people could use to register their thread local with spring, and have it transfered.
What I am thinking is something like:
Which could work for thread locals that are static fields, which afaik is most.
Anyways, just a thought.
···
On Mon, Feb 18, 2013 at 5:35 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
in GeoServer WPS we are using thread pools to manage the executions of the processes,
both direct calls and asynch ones are executed in their own thread pool to ensure
on one side resource control, on the other aysnch execution.
One of the troubles with the usage of thread pools is that they break thread locals,
some of which are pretty significant, such as the security ones (authentication),
but I’m also thinking about Dispatcher.RESPONSE, and others could be significant
as well.
In order for the WPS processes (and the catalog itself) to access said thread locals
we need to transfer them somehow into the other thread, and then clean them up.
Given this might serve a variety of purposes, I was thinking about an extension point
that would act in three stages:
- collect the thread local from the main thread, store it in some container
- once entered the pool’s thread, get it from the container and set it as a thread local in
the current thread
- once done clean up the thread local
How about something like:
interface ThreadLocalsTransferCallback {
/**
- Collects the current thread locals values into the storage
/
void collect(Map storage);
/*
- Set the thread local values in the current thread
/
void apply(Map storage);
/*
- Clean up the thread locals
*/
void cleanup();
}
The WPS code would then be extended to collect and use the callbacks in
ProcessCallable.
What do you think?
Cheers
Andrea
–
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
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - 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
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Tue, Feb 19, 2013 at 3:17 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Makes sense. So if I understand it an implementation of one of these interfaces would accompany every thread local we use?
Yep
I wonder if we could get away without an extension point, but rather just a utility class that people could use to register their thread local with spring, and have it transfered.
Hmm… seems limiting, not all thread locals are public.
But there is no reason why we can’t have both, general interface with convenience implementation for thread locals that are public?
Cheers
Andrea
–
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
On Tue, Feb 19, 2013 at 7:20 AM, Andrea Aime
<andrea.aime@anonymised.com>wrote:
On Tue, Feb 19, 2013 at 3:17 PM, Justin Deoliveira <jdeolive@anonymised.com>wrote:
Makes sense. So if I understand it an implementation of one of these
interfaces would accompany every thread local we use?
Yep
I wonder if we could get away without an extension point, but rather just
a utility class that people could use to register their thread local with
spring, and have it transfered.
Hmm... seems limiting, not all thread locals are public.
Right. For it to work the thread locals would have to be made visible,
either the field itself or through a method, which perhaps make the idea a
no go.
But there is no reason why we can't have both, general interface with
convenience implementation for thread locals that are public?
Sounds good.
Cheers
Andrea
--
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
-------------------------------------------------------
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.