RE: [Orekit Users] Threadsafe use of Orekit

[Rick Adams <adams@barron-associates.com>]

Luc,

Thanks for the quick response.  Data corruption in the Earth Orientation Parameters in the frames is the most common thread-related problem we've seen.  For example:

java.lang.NullPointerException
	at org.orekit.frames.AbstractEOPHistory.getInterpolatedField(AbstractEOPHistory.java:128)
	at org.orekit.frames.EOP2000History.getPoleCorrection(EOP2000History.java:89)
	at org.orekit.frames.TIRF2000Frame.getPoleCorrection(TIRF2000Frame.java:102)
	at org.orekit.frames.ITRF2005Frame.updateFrame(ITRF2005Frame.java:96)
	at org.orekit.frames.Frame.getTransformTo(Frame.java:164)
	at org.orekit.bodies.OneAxisEllipsoid.transform(OneAxisEllipsoid.java:232)

Rick

-----Original Message-----
From: MAISONOBE Luc [mailto:luc.maisonobe@c-s.fr] 
Sent: Thursday, February 24, 2011 3:35 PM
To: orekit-users@orekit.org
Subject: Re: [Orekit Users] Threadsafe use of Orekit

Hi,

adams@bainet.com a écrit :

> We are using Orekit in an Eclipse RCP application and have run into the
> non-thread safe issue for the singleton models.  I noticed you (the Orekit
> developers) already posted a bug report.

This problem is a known problem. There are several singletons used in  
Orekit that cache data for efficiency (JPL ephemerides, Earth  
Orientation Parameters ...). In multi-threaded programs, either you  
get data corruption if some code parts are not properly protected by  
"synchronized" blocks, or you get huge performance drops if some code  
parts are protected but the different thread invalidate the cache as  
they do not correspond to the same dates.

For now, Orekit is considered to be NOT thread safe.

>
> Is a fix in progress? We are having only limited success with workarounds.

As this problem is a frequent one and it would be very interesting to  
have a thread safe Orekit, we had some brainstorming in the  
development team. However, none of the ideas we had is implemented  
yet. This is a difficult problem and it will for sure take some time  
to solve it.

Our current idea is to replace some singletons by a pool of a few  
instances. The number of instances would be user configurable and  
should be related to the number of expected concurrent threads. When a  
thread would require some data, the pool element with the closest  
current date would be used and its current date adjusted.

This seems to us a reasonable solution to a classical use case: an  
application in which thread number i correspond to one computation  
that spans from t0(i) to t1(i). With this, switching from thread 1 to  
thread 2 and then back to thread 1 would simply mean we use the cache  
around dates t0(1) and t1(1) thanks to one pool element, then we use  
use the cache around dates t0(2) and t1(2) thanks to another pool  
element, then we go back to the first pool element. The trick is to  
still have the first pool element available and not be forced to  
re-read the JPL files for example if t0(1) and t0(2) are very far apart.

We don't think it would be wise to use the thread itself as the key to  
the pools elements because in a client-server application (for example  
a web service), the server threads may server requests from different  
clients.

I'm not sure this explanation is understandable. It is also for now  
only an idea, we did not implement it and we did not benchmark it.

Do you think it would correspond to your use case ?

Could you tell us which singletons are the most sensitive to  
multithreading (could be Earth Orientation Parameters in the frames,  
or JPL ephemerides for sun position ...) ?

I'm sorry to not have a ready to use solution.
Luc

>
> Has anyone else found a reasonable solution?
>
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.