[geotk] Can I prevent Geotoolkit from spawning new threads?

[Jon Blower]

Hi Martin,

GAE disables the creation of any threads.  I haven't found an
explanation but I assume it's so that they can do load-balancing
effectively.  Perhaps it ensures that new threads are only created in
response to HTTP requests, meaning that they can be distributed
between machines.  I'm not sure.

See http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox.

In my application, I'm basically using Gtk only for handling
coordinate reference systems.  If there was a way to instantiate a CRS
(e.g. from WKT) without spawning a background thread, this would
probably solve the problem for me.  Currently both CRS.decode() and
CRS.parseWKT() use a Factory, which seems to spawn a thread.

I can imagine that this is buried quite deep in the code, but it would
seem to be possible to create a CRS from WKT without a cleanup thread.
 Is there a way to access the "lower-level" methods that do this?

Cheers, Jon

On Tue, Oct 13, 2009 at 11:24 PM, Martin Desruisseaux
<martin.desruisseaux at geomatys.fr> wrote:
> Hello Jon
>
> There is currently no way to prevent Geotk to create new threads. The
> shutdown hooks are not the only ones created; there is also various cleaner
> threads which are running as daemon threads, for example for removing
> entries from WeakHashMap as they are garbage collected.
>
> It would be doable - while a bit unsafe - to disable the creation of
> shutdown hooks. But it would be more difficult to avoid the creation of
> other threads. However the issue may not be there. I'm not familiar with
> GAE, but I would be surprised if they disallow completly the creation of any
> Threads (if they really do so, then they probably explain their raisons
> somewhere and I would be curious to read them). Maybe they just set stricter
> constraints. The Thread constructor javadoc said:
>
>    If group is null and there is a security manager, the group is
>    determined by the security manager's getThreadGroup method.
>    (...snip...) If there is a security manager, its checkAccess
>    method is called with the ThreadGroup as its argument.
>
> So I think that the issue is that Geotk uses ThreadGroup. I could remove
> every usage of ThreadGroup - this change would be much easier and hurtless
> to apply than removing Threads. But before doing so I would be curious to
> see if GAE publishes any policy about ThreadGroup which would explain what
> we are supposed to do.
>
>        Martin
>
>
> Jon Blower a écrit :
>>
>> Hi,
>>
>> I've been experimenting with running Geotoolkit as part of a Google
>> App Engine application.  I have just discovered that GAE does not
>> allow applications to spawn new threads.  Unfortunately Geotoolkit
>> does this when calling CRS.getSupportedCodes() or CRS.decode().  The
>> creation of a ShutdownHook causes a security exception in GAE:
>>
>> java.lang.ExceptionInInitializerError
>>        at org.geotoolkit.factory.ShutdownHook.(ShutdownHook.java:55)
>>        at org.geotoolkit.factory.ShutdownHook.(ShutdownHook.java:41)
>>        at
>> org.geotoolkit.factory.FactoryFinder.getServiceRegistry(FactoryFinder.java:198)
>>        at
>> org.geotoolkit.factory.FactoryFinder.getFactories(FactoryFinder.java:216)
>>        at
>> org.geotoolkit.factory.AuthorityFactoryFinder.getCRSAuthorityFactories(AuthorityFactoryFinder.java:264)
>>        at
>> org.geotoolkit.referencing.DefaultAuthorityFactory.create(DefaultAuthorityFactory.java:92)
>>        at org.geotoolkit.referencing.CRS.getAuthorityFactory(CRS.java:219)
>>        at org.geotoolkit.referencing.CRS.decode(CRS.java:410)
>> ...
>> Caused by: java.security.AccessControlException: access denied
>> (java.lang.RuntimePermission modifyThreadGroup)
>>        at
>> java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
>>        at
>> java.security.AccessController.checkPermission(AccessController.java:546)
>>
>> I imagine that this might be hard, but is there any way of using Gtk
>> in such a way as that it does not spawn new threads?  By the way, it
>> seems to spawn threads even when using a "databaseless" CRS database,
>> i.e. with a static epsg.properties file.
>>
>> Thanks,
>> Jon
>>
>
>



-- 
Dr Jon Blower
Technical Director, Reading e-Science Centre
Environmental Systems Science Centre
University of Reading
Harry Pitt Building, 3 Earley Gate
Reading RG6 6AL. UK
Tel: +44 (0)118 378 5213
Fax: +44 (0)118 378 6413
j.d.blower at reading.ac.uk
http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm