[JBoss Microcontainer Development] New message: "Re: Native library mapping at jboss-cl level"
by Adrian Brock
JBoss development,
A new message was posted in the thread "Native library mapping at jboss-cl level":
http://community.jboss.org/message/521411#521411
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
> mailto:thomas.diesler@jboss.com wrote:
>
>
> > 1) It should be generating a unique name for the library so that it
> > can be hotdeployed (if the OS supports reloading native libraries).
> Areyou saying that the CLP should use a unique name as a key to some other service which then extracts the library on demand or provides that actual location in some other way? I believe the libname in http://java.sun.com/javase/6/docs/api/java/lang/System.html#loadLibrary(j... is such a key. The way this is currently modelled is that the CLP can be given NativeLibraryProvider interface, which get provide the lib location lazily.
> > 3)
> > You shouldn't use the BundleStoragePlugin. e.g. if this is running
> > inside JBossAS, the libraries should be extracted to server/xxx/temp not server/xxx/data
> Why is this distinction relevant? The bundle storage are can be used for all kinds of persistent data that relate to the bundle.
It is the URL of the library I'm talking about, the one returned from loadLibrary().
It should be unique to that particular instance of the bundle deployment, it shouldn't be persistant.
e.g. take an OS that supports hot deployment of native code, but locks the file of the library when it is loaded,
(i.e. the file system doesn't support file descriptors that have been deleted but are still open to some application)
The user then redeploys the bundle (possibly after changing the native code).
According to the OSGi rules, the uninstalled bundle should continue to use the previous version of the native code (until refreshPackages
gets used) while the new instance of the bundle sees the new native code.
You can't do that unless you generate a unique URL for each deployment of the bundle.
i.e. it is not persistent data, it should go in the tmp directory.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521411#521411
14 years, 5 months
[JBoss Microcontainer Development] New message: "ShutdownPolicy"
by Adrian Brock
JBoss development,
A new message was posted in the thread "ShutdownPolicy":
http://community.jboss.org/message/521403#521403
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
https://jira.jboss.org/jira/browse/JBCL-139
To support the OSGi semantics of not automatically re-resolving classloader dependencies
when you remove a classloader/deployment, I'm introducing a notion of ShutdownPolicy.
This currently has two options:
UNREGISTER - which is the current behaviour
GARBAGE_COLLECTION - let the classloader remain valid after it is unregistered
This can be set in two places.
1) ClassLoaderSystem/Domain - it then applies to all classloaders in that domain that don't explicitly specify it
2) ClassLoadingMetaData/Policy - in the xml it looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<classloader xmlns="urn:jboss:classloader:1.0"
name="test"
shutdown="GARBAGE_COLLECTION">
</classloader>
This effectively resolves https://jira.jboss.org/jira/browse/JBOSGI-206, except there's some work to do to implement the
"refreshPackages" behaviour in ClassLoading.
It also means that a Bundle update() can now be implemented as just a redeploy of the deployment (obviously there's a bit of extra
work required in the OSGiBundleManager to remember and restore the deployment to its previous state, e.g. the start/stop options).
NOTE: In the code I refer to the GC shutdown policy as "lazy shutdown", but also "cascading dependencies".
The second part comes from not unresolving dependent classloaders if we are in "lazy shutdown" mode. Since the classloader
is still valid, previous importers can still use it.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521403#521403
14 years, 5 months
[JBoss Messaging Development] New message: "Re: How do I shutdown JMS-connection for ClusteredConnectionFactory"
by Simo Nikula
JBoss development,
A new message was posted in the thread "How do I shutdown JMS-connection for ClusteredConnectionFactory":
http://community.jboss.org/message/521392#521392
Author : Simo Nikula
Profile : http://community.jboss.org/people/simo.nikula@capgemini.com
Message:
--------------------------------------------------------------
h2. Ports used
After prefix of 275 (standard jboss ports)
* 26 HAJNDI/RmiPort (1001)
* 50 JBM bisocket (1090)
* 71 JBM bisocket/secondaryBindPort (random, fixed due to firewall)
h3. Right after connection usage
{noformat}
[root@localhost /etc]# netstat -anp | grep ':275'
tcp 0 0 ::ffff:131.177.92.101:52296 ::ffff:131.177.70.47:27571 ESTABLISHED 13775/java
tcp 0 0 ::ffff:131.177.92.101:52332 ::ffff:131.177.70.47:27571 ESTABLISHED 13775/java
tcp 0 0 ::ffff:131.177.92.101:57994 ::ffff:131.177.70.47:27526 ESTABLISHED 13775/java
tcp 0 0 ::ffff:131.177.92.101:43689 ::ffff:131.177.70.47:27550 ESTABLISHED 13775/java
tcp 0 0 ::ffff:131.177.92.101:43685 ::ffff:131.177.70.47:27550 ESTABLISHED 13775/java
tcp 0 0 ::ffff:131.177.92.101:58688 ::ffff:131.177.70.46:27550 ESTABLISHED 13775/java
tcp 0 0 ::ffff:131.177.92.101:58652 ::ffff:131.177.70.46:27550 ESTABLISHED 13775/java
tcp 0 0 ::ffff:131.177.92.101:37998 ::ffff:131.177.70.46:27526 ESTABLISHED 13775/java
tcp 0 0 ::ffff:131.177.92.101:45526 ::ffff:131.177.70.46:27571 ESTABLISHED 13775/java
{noformat}
h3. after waiting for while after Connection.close()
{noformat}
[root@localhost /etc]# netstat -anp | grep ':275'
tcp 0 0 ::ffff:131.177.92.101:55895 ::ffff:131.177.70.47:27550 ESTABLISHED 13775/java
tcp 0 0 ::ffff:131.177.92.101:55894 ::ffff:131.177.70.47:27550 ESTABLISHED 13775/java
tcp 0 0 ::ffff:131.177.92.101:52332 ::ffff:131.177.70.47:27571 ESTABLISHED 13775/java
{noformat}
h4. connection is still pinged
{noformat}
[root@localhost /etc]# tcpdump -i any -nn 'port 27550 || port 27571'
tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
14:28:47.395349 IP 131.177.92.101.55894 > 131.177.70.47.27550: P 1940044237:1940044633(396) ack 2748921997 win 502 <nop,nop,timestamp 108477996 2903384612>
14:28:47.425310 IP 131.177.92.101.55894 > 131.177.70.47.27550: . ack 215 win 502 <nop,nop,timestamp 108478026 2903386614>
14:28:49.397282 IP 131.177.92.101.55894 > 131.177.70.47.27550: P 396:792(396) ack 215 win 502 <nop,nop,timestamp 108479998 2903386614>
14:28:49.426855 IP 131.177.92.101.55894 > 131.177.70.47.27550: . ack 429 win 502 <nop,nop,timestamp 108480027 2903388615>
14:28:51.399219 IP 131.177.92.101.55894 > 131.177.70.47.27550: P 792:1188(396) ack 429 win 502 <nop,nop,timestamp 108482000 2903388615>
14:28:51.428344 IP 131.177.92.101.55894 > 131.177.70.47.27550: . ack 643 win 502 <nop,nop,timestamp 108482029 2903390617>
14:28:51.478363 IP 131.177.92.101.55895 > 131.177.70.47.27550: . 1938645981:1938647285(1304) ack 2181599115 win 502 <nop,nop,timestamp 108482079 2903380720>
14:28:51.478426 IP 131.177.92.101.55895 > 131.177.70.47.27550: P 1304:1594(290) ack 1 win 502 <nop,nop,timestamp 108482079 2903380720>
14:28:51.535034 IP 131.177.92.101.55895 > 131.177.70.47.27550: . ack 439 win 502 <nop,nop,timestamp 108482136 2903390722>
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521392#521392
14 years, 5 months
[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"
by Thomas Diesler
JBoss development,
A new message was posted in the thread "Pluggable dependency resolver":
http://community.jboss.org/message/521271#521271
Author : Thomas Diesler
Profile : http://community.jboss.org/people/thomas.diesler@jboss.com
Message:
--------------------------------------------------------------
Am I right to understand that
* Each deployment bundle mapps to a ControllerContext.
* Each ControllerContext may have >0 dependencies.
* You call ResolverMatcher for each installed bundle
* You get multiple sets potential matches
How do you consolidate the sets of potential matches such that you end up with a consisten solution?
A1 can get wired to B1 and X1
B1 can get wired to X1 or X2
only when B1 gets wired to X1 can A1 get wired at all
Conceptually the MC resolver should support the semantics of
http://www.osgi.org/javadoc/r4v42/org/osgi/service/packageadmin/PackageAd...
also, there needs to be a notion of 'refresh', which may drop existing wirings and establish new ones to potentially updated bundles
http://www.osgi.org/javadoc/r4v42/org/osgi/service/packageadmin/PackageAd...
There is also a requirement to do a 'try run' of bundle resolution. This would allow to answer a question like: If I install these bundles will I end up with a consistent result where everything gets resolved? To answer this question the running system must not be affected - remember, you cannot "unresolve" a bundle.
In real life, you would give a provisioning system a small set of top level bundles and a pointer to a repository. The provisioning system needs to figure out if and how the complete set of transitive dependencies can be sattisfied before it modifies the running system in any way.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521271#521271
14 years, 5 months