On our system, we are adding a way to load eop and tai-utc data from a database instead of a flat file. We decided to create a data provider similar to the DirectoryCrawler, but instead of looking for a file when a specific data file is called, we are calling a service that reads from the database to serve the latest data available to us. We are still using the LazyLoadedDataContext implementation.
The problem we are facing is that our user will update the EOP often. We need to make sure we have hooks to reset orekit and let it use the new data.
From our debugging it seems that if we use the Lazy implementations we get some sort of caching. So when we try to force a data read the methods that we would expect to be called to initialize the Frames are not called. We do not want to have to reset my whole service in order to use newer data.
Is there a recommended way to deal with this issue on system that are persistent (like a web service) that need to load the data or reset the data every time we run something?
I seems that to accomplish what we need we would need to implement all the interfaces implemented by the LazyLoaded classes (like LazyLoadedFrames)
I’ve addressed this problem in the past in a couple of ways.
First, it’s important to understand the implications of updating EOP data. You probably don’t want to have the EOP data change out when your application is in the middle of processing a workload. This may create inconsistencies and incorrect computation within the workload. Consider propagation with an FoV inview detection. It could potentially be unfortunate if EOP changed halfway through propagation.
So, to prevent the data context changing during a workload execution I simply grab the default context at the start of the job. Then that context object must be passed explicitly into every constructor where it’s available. This eliminates the use of any methods or classes using the default context. If you’re writing a REST application, simply create a request-scoped producer method.
@RequestScoped @Produces
public DataContext produceContext() {
return DataContext.getDefault();
}
Now that you’ve guaranteed any one single workload will use a consistent data context, simply build a new LazyLoadedDataContext, adding your custom EOP data providers.
Depending on your update periodicity, i’ve generally run a scheduled task in a background thread that re-builds the data context every 24 hours or so. Simply create the new LazyLoadedDataContext, set your data providers, then call DataContext.setDefault() to replace the default data provider.
You can simply avoid the default data context entirely, holding your “current” data context in the producer class. But I haven’t seen a clear advantage in that approach.
Hi, I have an additional question: Does this mean that it is ensured, that orekit internally does not cache any data outside of a data context (e.g. by using singleton patterns and not updating the data again after initial construction / usage of the object)?
Hello everybody, sorry for taking back this conversation after a long time.
While documenting around the Orekit webpages and forum about the use of custom DataContext, the only doubt I’m getting so far is basically about this:
Then that context object must be passed explicitly into every constructor where it’s available
Specifically, the thing is - as far I can understand (but maybe I’m getting wrong something here) - not all Orekit classes where a DataContext is inherently used do provide constructors to inject a custom context.
A random example here:
the FrameAlignedProvider, according to its implementation in Orekit 12.0.2 version, is internally using only the DefaultDataContext and there’s apparently no way to supply a custom context.
Am I missing something?
Basically, my goal would be to have the possibility to use a custom data context everywhere throughout Orekit implementation, actually for the really same reasons well exposed in the messages above (recurring update of data for the application I’m developing).
If you find a class where you’re bound to use the Default DataContext then it’s a bug!
Please report it on the bug tracker.
Normally, all classes in Orekit that require a DataContext propose both implementations: one with the default DataContext (marked with annotation @DefautDataContextPlugin) and one with an implementation allowing the use of a custom DataContext.
In that particular case, we do use the Frame to pass the custom DataContext.
Method behavior:
@DefaultDataContext
public FrameAlignedProvider(final Rotation rotation) {
this(rotation, DataContext.getDefault().getFrames().getEME2000());
}
can be reproduced with a custom DataContext myDataContext using the 3rd constructor of the class and doing:
new FrameAlignedProvider(rotation, myDataContext.getFrames().getEME2000())
However, it’s true that in that case, Orekit does not provide an exact equivalent constructor…