bug #10252
openSession handling in name bulk editor not correct
0%
Description
What I did:
I updated the name ×Euphrasia arctica × stricta. In an intermediate state it became ×Euphrasia arctica ×stricta (so a nothosubsp. instead of a hybrid formula). This state was loaded (or created?) in the name bulk editor. Later I updated the name via the freetext taxon editor so it became the correct hybrid formula.
Now I wanted to reload the name bulk editor. I first tried with "Search" again but the name was still loaded and shown as "Euphrasia arctica nothosubsp. stricta". Inspecting the active session via the active session view did show that the name had no hybrid relationships, but via referencing objects view it did show hybrid relationships (so the session still seems to be the old one while the referencing objects view shows the up-to-date database state).
Then I closed the name bulk editor and reopened it. This resulted again in the old name state Euphrasia arctica nothosubsp. stricta.
To see if it is not a session issue but a general name bulk editor issue I opened a complete new TaxEditor and searched again for the name in the bulk editor. In this case the name was shown correctly and also the session view did show the 2 hybrid relationships.
So it seems that the name bulk editor does not fully throw away data once closed (or re-searched) but somehow keeps data in cache.
This can also be checked by using the session view and checking the java id of the name:
Here 1014877264. After closing the name editor and reopening it and do the same search it shows the same number (but shouldn't).
While the taxon editor shows another number:
and this number changes each time the taxon editor is reloaded which is the expected behavior.
Files
Related issues
Updated by Andreas Müller about 1 year ago
Interesting is that it does show the correct java object when searching via uuid, but only when opening a new name bulk editor, not if the name was searched via titleCache searche before in the same name bulk editor.
But then searching for the titleCache again in this new bulk editor which was first searched via uuid and did use a new java id does show the incorrect old record again BUT with the same java id as for the uuid search. So it does not seem to be a pure cache issue where an old java object is used for a new search. Maybe the old state is cloned or it is recomputed in a wrong way.
Also interesting: it also shows the incorrect hybrid flags in the details view (and in session view). It should show thy hybrid formula flag but it shows the trinom formula flag instead.
Updated by Andreas Müller about 1 year ago
I observed a similar incorrect session handling in other situations already. However, I never inspected it so deeply.
Updated by Andreas Müller about 1 year ago
It became even more strange. After closing all open editors (1 taxon editor and 1 agent bulk editor) and reopening the name bulk editor and searching in it I got:
last remote service : https://api.cybertaxonomy.org:443/euromed/remoting/name.service last remote method : getDbSchemaVersion last remote request client time : 2023-02-28T12:31:47.437 last remote request response header time : Tue, 28 Feb 2023 11:31:47 GMT client error time : 2023-02-28T12:31:47.772 login : admin editor version : 5.35.0 server : api.cybertaxonomy.org (cybertaxonomy.org) / euromed schema version : 5.35.1.0.20221218 os : Windows Server 2012 R2 6.3 amd64 java : 1.8.0_131 org.springframework.remoting.RemoteAccessException: Could not access HTTP invoker remote service at [https://api.cybertaxonomy.org:443/euromed/remoting/name.service]; nested exception is java.lang.RuntimeException: No cache available for cacheId = eu.etaxonomy.taxeditor.bulkeditor.input.AgentEditorInput1563987773. See #7699. Available caches are: [Ljava.lang.String;@3f423bdf CacheManager status is: STATUS_ALIVE Cache status is:STATUS_SHUTDOWN at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.convertHttpInvokerAccessException(HttpInvokerClientInterceptor.java:226) at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.invoke(HttpInvokerClientInterceptor.java:153) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213) at com.sun.proxy.$Proxy119.findByFullTitle(Unknown Source) at eu.etaxonomy.taxeditor.store.SearchManager.findNames(SearchManager.java:63) at eu.etaxonomy.taxeditor.bulkeditor.input.NameEditorInput.listEntities(NameEditorInput.java:146) at eu.etaxonomy.taxeditor.bulkeditor.input.AbstractBulkEditorInput.lambda$0(AbstractBulkEditorInput.java:304) at org.eclipse.core.runtime.jobs.Job$2.run(Job.java:186) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: java.lang.RuntimeException: No cache available for cacheId = eu.etaxonomy.taxeditor.bulkeditor.input.AgentEditorInput1563987773. See #7699. Available caches are: [Ljava.lang.String;@3f423bdf CacheManager status is: STATUS_ALIVE Cache status is:STATUS_SHUTDOWN at eu.etaxonomy.cdm.cache.CdmTransientEntityCacher.getCache(CdmTransientEntityCacher.java:153) at eu.etaxonomy.cdm.cache.CdmTransientEntityCacher.getCacheElement(CdmTransientEntityCacher.java:282) at eu.etaxonomy.cdm.cache.CdmTransientEntityCacher.getFromCache(CdmTransientEntityCacher.java:286) at eu.etaxonomy.cdm.cache.CdmTransientEntityCacher.putToCache(CdmTransientEntityCacher.java:250) at eu.etaxonomy.cdm.cache.CacheLoader.putToCache(CacheLoader.java:295) at eu.etaxonomy.cdm.cache.CacheLoader.loadRecursive(CacheLoader.java:322) at eu.etaxonomy.cdm.cache.CacheLoader.loadRecursiveAny(CacheLoader.java:84) at eu.etaxonomy.cdm.cache.CacheLoader.loadRecursiveCollection(CacheLoader.java:191) at eu.etaxonomy.cdm.cache.CacheLoader.load(CacheLoader.java:158) at eu.etaxonomy.cdm.cache.CacheLoader.load(CacheLoader.java:67) at eu.etaxonomy.cdm.cache.CdmTransientEntityCacher.load(CdmTransientEntityCacher.java:181) at eu.etaxonomy.taxeditor.session.CdmEntitySession.load(CdmEntitySession.java:66) at eu.etaxonomy.taxeditor.session.CdmEntitySessionManager.load(CdmEntitySessionManager.java:119) at org.springframework.remoting.httpinvoker.CachingHttpInvokerProxyFactoryBean.handleGeneralRequest(CachingHttpInvokerProxyFactoryBean.java:114) at org.springframework.remoting.httpinvoker.CachingHttpInvokerProxyFactoryBean.executeRequest(CachingHttpInvokerProxyFactoryBean.java:88) at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.invoke(HttpInvokerClientInterceptor.java:150) ... 8 more
So it tried to use the agent editor cache somehow instead of the new name bulk editor.
This is probably related to #7699
Updated by Andreas Müller about 1 year ago
- Related to bug #7699: NPE in CdmTransientEntityCacher.getCacheElement() added
Updated by Andreas Müller about 1 year ago
Note: also here the first bulk editor (agent bulk editor) was open for multiple days already