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.