Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » Multiple OSGi instances sharing same configuration area
Multiple OSGi instances sharing same configuration area [message #1234425] Tue, 21 January 2014 23:59 Go to next message
Shahim Essaid is currently offline Shahim EssaidFriend
Messages: 40
Registered: July 2009
Member
Hi All,

I'm trying to get a better understanding of Equinox and the OSGi launcher. I have few
questions about the use of the configuration area when multiple instances of the framework
are started from the same installation and no configuration area related parameters are
specified. I used the OSGi launcher pasted at the end of this post.

It appears that the same configuration area can be used by many running framework instances.
Each time I start a new framework, a new .manager/.tmp... and a new .bundledata.... is created.
I then tried to see how the starting and stopping of bundles in the different running instances
is handled in this case. I started bundle 3 (this was the launcher bundle that was in resolved state)
in one of the running instances and it was activated but the other instances remained resolved.
This makes sense since each instance appears to be keeping its state isolated from the other.
However, after I stoped all of them and restarted a new one, the new one shows the state to be
active for bundle 3, i.e. activating this bundle in any of the previously running instances was
persisted (regardless of the order in which the instances were exited). The other observation
is that even though the activation was persisted, if I start a new instance after starting
bundle 3 (without first shutting down all instances) the started state is not picked up by
later instances. When I start a new instance after shutting down all instances, I noticed that
the .manager/.tmp... files are cleaned up and a new one is created but the .bundlestate files are not.

I am somewhat familiar with the various OSGi runtime options and I will be experimenting with
them but I wanted to see how things work if no specific options are provided. Is it safe that
the configuration area can be used by multiple running OSGi instances? Are there any issues
that an OSGi, Equinox, or Eclipse based application can run into in this case? For example,
what are the consequences of running multiple Eclipse IDE instances at the same time from the
same configuration area? I didn't notice any problems when I tried this (with two different workspaces)
but I don't usually do this so I can't be sure that it will not cause any problems in the long run.

If this scenario is not supported, why isn't the configuration area locked the same way an
Eclipse workspace is locked to protect the user/developer from any problems? Does the OSGi
specification say anything about this or is this implementation specific?


Best,
Shahim

p.s. Is there a way to wrap wide posts? I used the web interface and my post was very wide
in the preview window so I manually wrapped it but didn't want to do the same with the following XML.

The launcher configuration I used:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<launchConfiguration type="org.eclipse.pde.ui.EquinoxLauncher">
<booleanAttribute key="append.args" value="true"/>
<booleanAttribute key="automaticAdd" value="false"/>
<booleanAttribute key="automaticValidate" value="false"/>
<stringAttribute key="bootstrap" value=""/>
<stringAttribute key="checked" value="[NONE]"/>
<booleanAttribute key="clearConfig" value="false"/>
<stringAttribute key="configLocation" value="${workspace_loc:_working-project/launcher_console}/config"/>
<booleanAttribute key="default" value="true"/>
<booleanAttribute key="default_auto_start" value="false"/>
<intAttribute key="default_start_level" value="4"/>
<booleanAttribute key="includeOptional" value="false"/>
<stringAttribute key="org.eclipse.debug.ui.ATTR_CAPTURE_IN_FILE" value="${workspace_loc:/_working-project/launcher_console}/logfile.txt"/>
<booleanAttribute key="org.eclipse.jdt.launching.ATTR_USE_START_ON_FIRST_THREAD" value="true"/>
<stringAttribute key="org.eclipse.jdt.launching.JRE_CONTAINER" value="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.7"/>
<stringAttribute key="org.eclipse.jdt.launching.PROGRAM_ARGUMENTS" value="-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -noExit -console -consoleLog"/>
<stringAttribute key="org.eclipse.jdt.launching.SOURCE_PATH_PROVIDER" value="org.eclipse.pde.ui.workbenchClasspathProvider"/>
<stringAttribute key="org.eclipse.jdt.launching.VM_ARGUMENTS" value="-Declipse.ignoreApp=true -Dosgi.noShutdown=true"/>
<stringAttribute key="org.eclipse.jdt.launching.WORKING_DIRECTORY" value="${workspace_loc:_working-project/launcher_console}"/>
<stringAttribute key="pde.version" value="3.3"/>
<booleanAttribute key="show_selected_only" value="true"/>
<stringAttribute key="target_bundles" value="org.apache.felix.gogo.command@6:false,org.apache.felix.gogo.runtime@default:default,org.apache.felix.gogo.shell@default:default,org.eclipse.equinox.console@default:default,org.eclipse.equinox.launcher.gtk.linux.x86_64@default:false,org.eclipse.equinox.launcher@default:default,org.eclipse.equinox.transforms.hook@default:false,org.eclipse.osgi@-1:true"/>
<booleanAttribute key="tracing" value="false"/>
<booleanAttribute key="useCustomFeatures" value="false"/>
<booleanAttribute key="useDefaultConfigArea" value="false"/>
</launchConfiguration>

Re: Multiple OSGi instances sharing same configuration area [message #1234655 is a reply to message #1234425] Wed, 22 January 2014 13:40 Go to previous messageGo to next message
Thomas Watson is currently offline Thomas WatsonFriend
Messages: 437
Registered: July 2009
Senior Member
The equinox configuration area is able to handle multiple instances running from it but it has some caveats. In general the configuration area should only be shared between to running instances that are not planning to install any new bundles or change the persistent settings of the bundles (start-level, persistent starts etc.). The behavior you see with multiple instances is because equinox delays the persistence of its data so that we do not do massive amounts of IO. For example, when installing 100 bundles we do not persist settings for each bundle one at a time, instead we post a save request in the background that waits for some period of inactivity before saving to disk. Then after all 100 bundles are installed we can do one save to disk. So if you make one persistent change in one instance and then quickly start another instance, the new instance may not see the persistent change.

This model works fine for the IDE because the Eclipse IDE generally never makes persistent changes to the framework in its normal operation. Only when updating/installing/uninstalling features with p2 does it do this.

HTH

Tom
Re: Multiple OSGi instances sharing same configuration area [message #1234772 is a reply to message #1234655] Wed, 22 January 2014 19:18 Go to previous messageGo to next message
Shahim Essaid is currently offline Shahim EssaidFriend
Messages: 40
Registered: July 2009
Member
Hi Tom,

Thank you for the information, very helpful. So if I add P2 to this picture (I haven't played with this yet) what is the recommended OSGi/Equinox approach for allowing two running framework instances (of the same install and configuration area) to use P2 to perform provisioning operations? For example, if instance A starts a provisioning session on the local P2 area, can instance B also use P2 as a later time? I am assuming that A and B can't have different agents open for the same P2 area so how does P2 handle this if it occurs? And will the P2 agent in instance A allow a later agent in instance B to perform an operation assuming the first one is finished? Also, after provisioning is finished in A, B, etc. how can one framework instance notify other instances to "reload" the new provisioned state? Is there a generic way for doing this without having restart the instances or having to write a specific protocol for doing this?

I don't have a very specific use-case in mind that I need to address. I'm just trying to have a good understanding of these interactions so that I can take better advantage of OSGi/Equinox.

Thanks,
Shahim

[Updated on: Wed, 22 January 2014 19:22]

Report message to a moderator

Re: Multiple OSGi instances sharing same configuration area [message #1234780 is a reply to message #1234772] Wed, 22 January 2014 19:42 Go to previous messageGo to next message
Shahim Essaid is currently offline Shahim EssaidFriend
Messages: 40
Registered: July 2009
Member
Also, does it matter if any of this is done within one JVM vs multiple JVMs?
Re: Multiple OSGi instances sharing same configuration area [message #1236556 is a reply to message #1234772] Mon, 27 January 2014 14:19 Go to previous message
Thomas Watson is currently offline Thomas WatsonFriend
Messages: 437
Registered: July 2009
Senior Member
Probably worth a post to the p2 forum. My understanding is that p2 performs operations at a meta-data level above the framework (what p2 refers to as a p2 profile). So when you do a p2 provisioning operation it does not necessarily affect the instance of Equinox that is running the agent. An agent can point at any p2 profile, including the profile being used to configure the currently running instance. The "configurator" then needs to be kicked in the instances that is using the p2 profile you just updated to make it take effect at runtime. Usually that involves a restart of that eclipse instance.
Previous Topic:Tutorial: p2 updates for Eclipse RCP applications
Next Topic:where can I find and download the org\eclipse\osgi\framework\internal\core\BundleHost.java
Goto Forum:
  


Current Time: Wed Nov 26 02:00:06 GMT 2014

Powered by FUDForum. Page generated in 0.45056 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software