Matthew, some followup to the problem quoted below. Eventually, I've found the order of jars on classpath does not seem to be the culprit; the problem seem to be caused by...
occasionally (not too often), we are running a background import task, which uses its own EO stack: at launch, it creates a new EOObjectStoreCoordinator (and for it it creates an ERXEC and uses it to import data). When done and saved, the coordinator is disposed and released.
I don't have an answer to your specific EOObjectStoreCoordinator woes, sorry.
Could you run your background task in a separate instance or machine? For high resource background tasks that's what we do, running a specialised instance on-demand, which uses JGroupsSync to coordinate with other machines and instances when needed.
Thanks!
I sort of fear the problems might stay: they are not — far as I can say — caused by the concurrence betwixt the import thread and the workers, but rather by somewhat unpredictable moment when the Coordinator's own thread bumps in and starts to coordinate. Which would be needed anyway.
I did a number of improvements meantime — e.g., whilst I am, so far, really not able to find why on earth sometimes the coordinator throws the ObjectNotAvailableException for an object which does exist and ever did, I've tried to alleviate the problem using the tolerantEntityPattern to block the exception, whatever causes it. Seems it helped, so far (touching wood ;))
If the worst comes to the worst, I guess we can switch off the Coordinator completely and coordinate manually: we use background threads with their own EO stacks pretty rarely and for a very small set of well-defined operations (the aforementioned import, not-yet mentioned pre-computing of some cached data, and that's all), and we never use separate EO stacks for normal workers; thus a manual coordination would not be too difficult.
Thanks again and all the best, OC
|