Multiple OSGi instances sharing same configuration area [message #1234425] |
Tue, 21 January 2014 23:59 |
Shahim Essaid 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 #1234772 is a reply to message #1234655] |
Wed, 22 January 2014 19:18 |
Shahim Essaid 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
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02185 seconds