|
|
Re: [CDO] Way to open and close repository thanks to an admin repository [message #1780912 is a reply to message #1780883] |
Mon, 29 January 2018 22:27 |
|
Hi, Cyril,
My memory of how the remote administration of CDO repositories works is faint, and it has been a long time since I did any work on the implementation. Happily, I did document it in some degree on my blog:
CDO Repository Administration
This includes a video demonstration of how the feature works in a Papyrus context from back in the Luna release, plus a link to the Bugzilla work item that has further references to the specific commits in Git that implement the feature.
I'm not sure whether the repository administration scenarios implemented in Luna support your needs. We provide for creation and deletion of repositories, but it sounds like you need additionally to be able to publish or hide repositories from users. That could be a new requirement that we don't support (yet). With luck, this reply provides enough pointers to glean the answers you need.
HTH,
Christian
|
|
|
|
|
|
|
Re: [CDO] Way to open and close repository thanks to an admin repository [message #1782054 is a reply to message #1781175] |
Fri, 16 February 2018 14:10 |
Cyril Chevé Messages: 14 Registered: October 2016 |
Junior Member |
|
|
Hi Eike,
Thanks for your answer. That helped me a lot. :)
For the moment, I have implemented the following methods in the CDOAdmin framework :
• public boolean activateRepository(String name, String type);
• public boolean deactivateRepository(String name, String type);
• public boolean isActivatedRepository(String name, String type);
For the inactive repositories, I get them from the catalog in DefaultCDORepositoryConfigurationManager.java.
For me, the implemented deactivation consists in calling the method LifecycleUtil.deactivate() on a IRepository.
I have made some tests and it seems to work.
But I have some more questions :
• One of my tests consists in doing sequentially 100 times: 1/ create a repository, 2/ add 100000 objects, 3/ deactivate the repository. Regarding the used heap memory of the CDO server, I expected that it would be stable after each deactivation but the amount of used memory is continiously growing until the heap max. Moreover, when the used heap memory is just below the max, the CDO server seems to slow down and there are more TimeoutException during commit or deactivation. Does it seem ok for you ? Are there some references or a cache to empty after one deactivation ? Do you have any idea about the elements that can stay in memory after the deactivation ?
• Do you have some advices regarding the modification of the API interfaces and plugin versions ?
Thanks in advance.
Cyril
|
|
|
Re: [CDO] Way to open and close repository thanks to an admin repository [message #1782056 is a reply to message #1782054] |
Fri, 16 February 2018 14:56 |
|
Cyril Chevé wrote on Fri, 16 February 2018 15:10
• One of my tests consists in doing sequentially 100 times: 1/ create a repository, 2/ add 100000 objects, 3/ deactivate the repository. Regarding the used heap memory of the CDO server, I expected that it would be stable after each deactivation but the amount of used memory is continiously growing until the heap max. Moreover, when the used heap memory is just below the max, the CDO server seems to slow down and there are more TimeoutException during commit or deactivation. Does it seem ok for you ? Are there some references or a cache to empty after one deactivation ? Do you have any idea about the elements that can stay in memory after the deactivation ?
To me that sounds like normal Java garbage collection characteristics. Please try to call java.lang.System.gc() after the deactivation of a repository. Does that change the characteristics?
Cyril Chevé wrote on Fri, 16 February 2018 15:10
• Do you have some advices regarding the modification of the API interfaces and plugin versions ?
The rules of https://wiki.eclipse.org/Evolving_Java-based_APIs apply to all public APIs and are automatically enforced by PDE API Tools (e.g., if you installed your workspace with Oomph). We're not planning for a major release, so API changes that require a major version increment are prohibited. In particular that means you must not add methods to public interfaces. Instead you should introduce extension interfaces, let the default implementations implement these extension interfaces, and let the client code do instanceof checks for (and downcasts to) these extension interfaces. With this trick you're only required to increment the minor versions of the affected API plugins (if that didn't already happen in the current release cycle). Makes sense?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
|
|
|
Re: [CDO] Way to open and close repository thanks to an admin repository [message #1783725 is a reply to message #1783247] |
Fri, 16 March 2018 10:02 |
Cyril Chevé Messages: 14 Registered: October 2016 |
Junior Member |
|
|
Hello,
I have done some modifications in the class HorizontalNonAuditClassMapping.java in order to be sure that this class keeps the references to the deactivated repositories.
So I have added:
• in HorizontalNonAuditClassMapping$FeatureDeltaWriter inner class, a method to set the field accessor to null,
• in the finally block in HorizontalNonAuditClassMapping.writeRevisionDelta() method, a call to this added method and a call to deltaWriter.remove().
With these modifications, the used heap memory is quite stable (see screenshot).
But I am not sure about the side effects of these modifications because accessor is also used in the visit() method. Does it seem good for you ?
Could the fact to remove the ThreadLocal have an impact on performances ?
Moreover, I have done the same kind of test but, instead of deactivating the repositories, I remove the repositories with the existing api. The heap memory behaves in the same way.
Thanks.
Cyril
[Updated on: Fri, 16 March 2018 16:18] Report message to a moderator
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03954 seconds