November 2009 - jboss-dev-forums - Jboss List Archives

[JBoss AS Development] - Re: Graceful Shutdown

by bstansberry＠jboss.com

"bstansberry(a)jboss.com" wrote : "emuckenhuber" wrote : Hmm graceful shutdown should not be part of the MC bean lifecycle, as it would then always shutdown in a graceful manner. This should be an optional way to shutdown AS - triggered with a different signal or management action. | | Additionally with the graceful shutdown there will most likely be a timeout which then is going just stop AS. This does not seem to fit very well with MC lifecycle actions, since we would basically need to interrupt a action during a state transition (pre_stop -> stop). | | With the acceptor concept we should be able to deal with these issues even though we're essentially using the MC lifecycle. | | The acceptors can all be registered with a central management bean that can set a property as to how long they should wait to return from stop(). -1, don't do anything, just return, 0 wait as long as it takes, > 0, wait that long. The default is -1 or something configurable at the server level. The management console sets to something else if a graceful shutdown is invoked. As I wrote this it felt hacky, and it is. Emanuel, your instincts and Jason's are right; this isn't really an MC issue. It's a step in the shutdown process that occurs before the normal undeployment process starts. If we have a bunch of acceptors, whatever is controlling the shutdown can tell them to stop; we don't need the MC to do it. That is back to the original design we discussed in Westford. "jason.greene(a)redhat.com" wrote : Let me give an example. Someone defines a service A, which supports remote invocation. There is no dependency between service A and the EJB container (Service B), because it doesn't make sense (they have nothing to do with each other). Then instance SFSB Foo of Service B *dynamically* decides to call service A during an invocation. Then during "graceful" shutdown, service A is stopped first. Jason, are you concerned about solving this case (eventually), or are you just using it to make a point about dependencies? Segregating internal calls from those coming via remote endpoints, and then closing off the remote endpoints before stopping/undeploying anything will handle most such cases. The only ones it won't are where Service B makes a remote call to non-HA Service A, even though both are deployed locally. Which case is IMHO out of scope. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267561#4267561 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267561

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Double Module::reset invocation

by alesj

"alesj" wrote : | This is an old discussion, that as I see it now, never got properly resolved: | http://www.jboss.org/index.html?module=bb&op=viewtopic&t=146461 | But afair, vaguely, Adrian mentioned that both calls to resent are needed. As things might break in any of the two used stages, and you need a proper cleanup. If all things go OK, 2nd call is a noop, but you don't know if things will go well. I guess Adrian can shed some more light on the subject. ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267552#4267552 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267552

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Double Module::reset invocation

by alesj

"flavia.rainone(a)jboss.com" wrote : | - the call to Module.reset() is duplicated.AbstractLevelClassLoaderSystemDeployer.removeClassLoader() directly invokes reset; and VFSClassLoaderDescribeDeployer invokes it indirectly, as it invokes ClassLoading.removeModule() which in turn invokes reset. | Is this expected? In the case of the class pools, RegisterModuleCallback is invoked by ClassLoading.removeModule(). At this point, ClassLoading hasn't reset the module yet, but AbstractLevelCLSystemDeployer has already done it. Despite that, RegisterModuleCallback needs to retrieve the package names, thus causing the module to reload the capability collection.. To get rid of this overhead, of course I could add a map to keep track of the package names associated with a module, avoiding the call to module.getPackageNames(). But isn't it expected that other module registries being notified of a removeModule may want to use the capability collection of the module as well? If the answer is yes, I think the module shouldn't be reset at this time. | This is an old discussion, that as I see it now, never got properly resolved: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=146461 "flavia.rainone(a)jboss.com" wrote : | - I noticed that the PackageVisitor.determineAllPackages method returns the META-INF as an exported package name. Is this filtered out sometime later during execution? How else would a call to ClassLoader::getResource("META-INF/some-config.xml") work? ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267550#4267550 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267550

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by alesj

"flavia.rainone(a)jboss.com" wrote : | Ales, you mentioned on a private chat that jboss-classpool should not use VFS because that would result in a circular dependency. Have you taken a look at the class pool tests? They already use VFS stuff, even though the pom doesn't declare any direct dependency to VFS. I wonder if those tests are ok or if I'll have to "fix" them, by removing the VFS part. | No, I meant Deployers-VFS. Using VFS is of course fine, as it helps you assemble archives to test. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267546#4267546 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267546

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Supporting qualifiers in MC

by kabir.khan＠jboss.com

Speaking to Ales he mentioned that: "@Inject should pick up qualifiers from annotations" I think this should also be done when inject is done via xml/beanmetadata. Since most qualifiers I've seen (in jsr-299 and jsr-330) are picked out using annotations on the annotation, I propose adding something to BeanAnnotationAdapter to handle meta-annotations. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267538#4267538 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267538

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - VFS deployers and CL behaviour

by flavia.rainone＠jboss.com

During debugging of the class pool/vfs tests, two things called my attention: - the call to Module.reset() is duplicated.AbstractLevelClassLoaderSystemDeployer.removeClassLoader() directly invokes reset; and VFSClassLoaderDescribeDeployer invokes it indirectly, as it invokes ClassLoading.removeModule() which in turn invokes reset. Is this expected? In the case of the class pools, RegisterModuleCallback is invoked by ClassLoading.removeModule(). At this point, ClassLoading hasn't reset the module yet, but AbstractLevelCLSystemDeployer has already done it. Despite that, RegisterModuleCallback needs to retrieve the package names, thus causing the module to reload the capability collection.. To get rid of this overhead, of course I could add a map to keep track of the package names associated with a module, avoiding the call to module.getPackageNames(). But isn't it expected that other module registries being notified of a removeModule may want to use the capability collection of the module as well? If the answer is yes, I think the module shouldn't be reset at this time. - I noticed that the PackageVisitor.determineAllPackages method returns the META-INF as an exported package name. Is this filtered out sometime later during execution? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267533#4267533 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267533

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

"alesj" wrote : "flavia.rainone(a)jboss.com" wrote : Now, I don't know if we need to port the vfs tests to class pool or not. Maybe I should only port the "key" tests, that uncovered bugs. | | | Something definitely needs porting, or any form of "duplication". | As these errors should already be spotted in the Classpool project itself. | I started porting this tests and It looks like I've already found another bug :( Apparently, bootstrap classes are being loaded by the wrong class pool. Ales, you mentioned on a private chat that jboss-classpool should not use VFS because that would result in a circular dependency. Have you taken a look at the class pool tests? They already use VFS stuff, even though the pom doesn't declare any direct dependency to VFS. I wonder if those tests are ok or if I'll have to "fix" them, by removing the VFS part. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267526#4267526 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267526

14 years, 5 months

1
0
0 / 0

[JBoss Profiler Development] - Re: JBoss Profiler snapshot doesn't work

by mbalazs

If stopProfiler or snapshot doesn't return, try to set "jsf=no" in jboss-profiler.properties. I had this problem, and eventually I've found out that the jsf profiler tryes to validate XML documents at some point during the stopProfiler call, and it needs to access external web sites to do so. Our firewall was blocking outgoing requests, so all XML validation attempts had to wait until the connection timed out. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267495#4267495 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267495

14 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Supporting qualifiers in MC

by kabir.khan＠jboss.com

What I have so far: https://jira.jboss.org/jira/browse/JBKERNEL-63 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267475#4267475 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267475

14 years, 5 months

1
0
0 / 0

[JBoss Web Services Development] - Re: Create new deployer to deploy java first jms transport w

by richard.opalka＠jboss.com

Your investigation Jim is correct. I'd postpone this task until we'll meet each other and will discuss this issue face to face. Take a look to other tasks, please. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267450#4267450 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267450

14 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums November 2009