January 2010 - jboss-dev-forums - Jboss List Archives

[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

16 years, 2 months

1
0
0 / 0

[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

16 years, 2 months

1
0
0 / 0

[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

16 years, 2 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Native library mapping at jboss-cl level"

by Thomas Diesler

JBoss development, A new message was posted in the thread "Native library mapping at jboss-cl level": http://community.jboss.org/message/521389#521389 Author : Thomas Diesler Profile : http://community.jboss.org/people/thomas.diesler@jboss.com Message: -------------------------------------------------------------- jboss-cl http://fisheye.jboss.org/changelog/JBossAS/projects/jboss-cl?cs=99732 I added http://fisheye.jboss.org/browse/JBossAS/projects/jboss-cl/trunk/classload... http://fisheye.jboss.org/browse/JBossAS/projects/jboss-cl/trunk/classload...: wich gets initialized by http://fisheye.jboss.org/browse/JBossAS/projects/jboss-osgi/projects/runt...:. At resolve time, the http://fisheye.jboss.org/browse/JBossAS/projects/jboss-osgi/projects/runt...: adds NativeLibraryProvider instances to the http://fisheye.jboss.org/browse/JBossAS/projects/jboss-cl/trunk/classload...: which are accessed by the http://fisheye.jboss.org/browse/JBossAS/projects/jboss-cl/trunk/classload...: like this protected String findLibrary(String libname) { String libraryPath = null; if (policy != null) libraryPath = policy.findLibrary(libname); if (libraryPath == null) libraryPath = super.findLibrary(libname); return libraryPath; } Test coverage in framework still needs to get done. This is currently only tested in the TCK. XML -> CLMD mapping is also not done. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521389#521389

16 years, 2 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"

by Kabir Khan

JBoss development, A new message was posted in the thread "Pluggable dependency resolver": http://community.jboss.org/message/521379#521379 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- I noticed that some test where dependency items come from annotations were failing, so I have fixed that by adding a dependency item decorator that tracks when dependency items are added/removed and pushes those to the index. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521379#521379

16 years, 2 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"

by Kabir Khan

JBoss development, A new message was posted in the thread "Pluggable dependency resolver": http://community.jboss.org/message/521308#521308 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- Thomas, For now I am working on making the main dependency resolution algorithm pluggable and supplying an optimized version. Once that is done, I will look into your requirements -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521308#521308

16 years, 2 months

1
0
0 / 0

[JBoss Messaging Development] New message: "Re: How do I shutdown JMS-connection for ClusteredConnectionFactory"

by Yong Hao Gao

JBoss development, A new message was posted in the thread "How do I shutdown JMS-connection for ClusteredConnectionFactory": http://community.jboss.org/message/521295#521295 Author : Yong Hao Gao Profile : http://community.jboss.org/people/gaohoward Message: -------------------------------------------------------------- Hi Simo, Each time you create a connection, the client will get a new connection to one of your cluster servers. That means for each connection got from createTopicConnection(), you need to close it. if you have the output of lsof/tcpdump that can prove the connection ping, can you post here so I can have a better understanding of the issue? Thanks Howard -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521295#521295

16 years, 2 months

1
0
0 / 0

[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/521285#521285 Author : Simo Nikula Profile : http://community.jboss.org/people/simo.nikula@capgemini.com Message: -------------------------------------------------------------- Hi Howard, I maybe should have used user forum but this may turn into development issue. I have cluster of two servers. closing code is just javax.jms.Connection.close(); Connection is obtained by basically (typecasting left out) InitialContext.lookup("/ClusteredConnectionFactory").createTopicConnection(); When I check with lsof and tcpdump only connection to one server is closed and pinging continues on other. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521285#521285

16 years, 2 months

1
0
0 / 0

[JBoss Messaging Development] New message: "Re: How do I shutdown JMS-connection for ClusteredConnectionFactory"

by Yong Hao Gao

JBoss development, A new message was posted in the thread "How do I shutdown JMS-connection for ClusteredConnectionFactory": http://community.jboss.org/message/521272#521272 Author : Yong Hao Gao Profile : http://community.jboss.org/people/gaohoward Message: -------------------------------------------------------------- Hi Simo, I'm not sure I understand your issue, can you give me the code piece that you use to close the connections? By the way, for user related problems we have a user forum. This forum is for development only. Thanks Howard -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/521272#521272

16 years, 2 months

1
0
0 / 0

[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

16 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2010