[JBoss AS Development] - Re: Graceful Shutdown
by jason.greene＠jboss.com
"ALRubinger" wrote :
| What's an invocation which was triggered by an EJB Timer; internal or external?
|
Internal.
anonymous wrote :
| Also we've talked about a separation between services and deployments.; but services are deployments themselves. Deployments may depend both upon each other and upon services. Services may depend upon each other. In this light I think the standard MC dependency mechanism will suffice.
|
MC dependencies don't make sense in this case. MC deps are internal service implementation details, and don't necessarily reflect the current runtime behavior. Graceful shutdown is all about the enclosing request (or transaction).
anonymous wrote :
| To me the tricky part is extracting out all the endpoints (acceptors) and ensuring all moving parts are explicitly wired together.
|
We can start small. First implement this kind of thing for the web layer, that will handle 90% of what people are after (Brian's idea).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267387#4267387
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267387
14 years, 5 months
[JBoss AS Development] - Re: Naming over Remoting 3
by ron.sigal＠jboss.com
"ALRubinger" wrote :
| Its real value is in a wire protocol that's tested for both forward- and backward-compatibility. Basically the class InvocationImpl and its tests.
|
I really enjoyed that.
"ALRubinger" wrote :
| But then again, that's the scope of the thing. Its intended to be extended via composition to add on your requirements, or supplemented w/ JBMAR or R3.
|
If it's intended to be generally extensible, then isn't "ejb3" in the package names misleading? How about "invokable" in place of "ejb3"?
"david.lloyd(a)jboss.com" wrote :
| If what you're implementing is a service (such as JNDI for example) which can be expressed in terms of a fixed set of request and reply types, it's better/cleaner/simpler/more efficient to get rid of the remote proxy idea and just use straight request/reply objects directly.
|
OK, makes sense. One nice thing about the proxy factories, though, is that they have a built in mechanism for handling interceptors. I guess there's no reason a chain of interceptors couldn't be downloaded by a Naming client, but
1. the Naming client would probably end up packaging an invocation and sending it down the interceptor chain, acting just like a proxy, and
2. the Naming client would have its own implementation of the general proxy mechanism.
"ron.sigal(a)jboss.com" wrote :
| And what about the org.jboss.proxy.* stuff? Will it stay where it is, or, maybe, move to invokablecontainer?
|
If invokablecontainer doesn't want the proxy stuff, how about a Proxy project that builds on invokablecontainer?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267378#4267378
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267378
14 years, 5 months
[JBoss AS Development] - Re: Graceful Shutdown
by ALRubinger
"ALRubinger" wrote : The key concept is to separate internal requests from external requests, with the acceptor acting as a gate on the external requests. So graceful shutdown ends external requests, while still leaving the possibility of internal requests, e.g. web tier calling into an EJB. For the internal requests, the normal dependency mechanism (web app depends on ejb) ensures the EJB doesn't undeploy before the webapp is undeployed.
To copy myself a bit from a #jboss-dev IRC talk:
What's an invocation which was triggered by an EJB Timer; internal or external? While I like the notion of separating out acceptors/processors, I think the context of the request/session in progress is not always so clear.
Also we've talked about a separation between services and deployments.; but services are deployments themselves. Deployments may depend both upon each other and upon services. Services may depend upon each other. In this light I think the standard MC dependency mechanism will suffice.
To me the tricky part is extracting out all the endpoints (acceptors) and ensuring all moving parts are explicitly wired together.
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267364#4267364
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267364
14 years, 5 months
[JBoss AS Development] - Re: Graceful Shutdown
by bstansberry＠jboss.com
Could the deployment of the acceptor be part of the deployment of the service? It's just a separate MC bean that depends on the core service.
That eliminates the issue of deployment phases.
I want to restate my understanding of David's idea in case I have it wrong. :-) The key concept is to separate internal requests from external requests, with the acceptor acting as a gate on the external requests. So graceful shutdown ends external requests, while still leaving the possibility of internal requests, e.g. web tier calling into an EJB. For the internal requests, the normal dependency mechanism (web app depends on ejb) ensures the EJB doesn't undeploy before the webapp is undeployed.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267341#4267341
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267341
14 years, 5 months
[JBoss Microcontainer Development] - Re: Supporting qualifiers in MC
by kabir.khan＠jboss.com
"kabir.khan(a)jboss.com" wrote :
| The search algorithm works much the same as before. ClassAndQualifierKey queries for all the beans implementing a class, and then narrows it down depending on the wanted qualifiers and the required qualifiers.
| EDIT: The qualifiers now are looked up from the MDR for the contexts involved
|
I forgot to mention that in the case of qualifier metadata existing at a higher level in MDR than instance level, the search takes that into account and merges whatever it can find at all levels. e.g., if ["a", "b"] exists at JVM level and ["c", "d"] at INSTANCE level, when doing the lookup for an instance ["a", "b", "c", "d"] is returned.
"kabir.khan(a)jboss.com" wrote :
| It should be possible to specify qualifiers for injected parameters and properties, so that in this example we can say the constructor wants the Bean with qualifier 'A' while the setter wants the Bean with the qualifier 'B'. I'll see if I can use/expand AbstractInjectionValueMetaData to use qualifiers.
I've done this. This differs from the bean-level qualifiers in that if a qualifier exists on an injection point, then the bean-level qualifiers are ignored, so the property level ones completely override the bean level ones e.g.
| class TargetBean
| {
| Bean bean1;
|
| Bean bean2;
| }
|
If the bean has RelatedClassMetaData specifying that it's wanted qualifiers are 'A', and the property bean2 specifies that the qualifiers are 'B', for bean1 we will inject a bean that supplies the qualifier 'A', while for bean2 a bean that supplies the qualifier 'B' will be injected.
I don't know if the qualifiers for the injection points should be read from the MDR or not? At first glance doing that does not make sense since the component metadata lives below instance level, but I might be wrong. Especially if my previous assumption that injection point qualifiers should completely override the bean-level wanted qualifiers is wrong?
I'll add some xml configuration for everything before I commit
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267334#4267334
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267334
14 years, 5 months
[JBoss AS Development] - Re: Graceful Shutdown
by bstansberry＠jboss.com
"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.
The acceptors should have a thread pool injected so they use a pool thread to actually perform the graceful shutdown work (with a Future). So the thread calling in from the MC won't have to be interrupted in some arbitrary code; it's just blocking in a future.
It's the responsibility of the acceptor impls (or more likely some element of the container they're associated with) to ensure that if a graceful shutdown is requested and is still in progress they can still cleanly perform their normal stop() processing. I don't think this should be hard. As I see it, the graceful shutdown task would be to:
1) If possible, signal load balancing mechanism that this node shouldn't receive new sessions, or new requests if requests are the relevant unit of work.
.. some details skipped...
2) Wait for existing work to complete.
3) Close a gate such that requests for new work raise an exception, generate an HTTP 503 etc.
It shouldn't be hard to ensure that a normal stop() can proceed even if the above isn't complete.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267328#4267328
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267328
14 years, 5 months
[JBoss Microcontainer Development] - ScopeInfo's MetaData handling looks inconsistent
by alesj
We add/remove the MetaData with mutable key:
| public void addMetaData(MutableMetaDataRepository repository, ControllerContext context)
| {
| this.repository = repository;
| ScopeKey scope = getMutableScope();
| MetaDataRetrieval retrieval = repository.getMetaDataRetrieval(scope);
| MutableMetaDataLoader mutable;
| if (retrieval == null)
| {
| mutable = initMutableMetaDataRetrieval(repository, context, scope);
| repository.addMetaDataRetrieval(mutable);
| addedScopes.add(scope);
| }
| else
| {
| mutable = getMutableMetaDataLoader(retrieval);
| }
|
| if (mutable == null)
| {
| log.warn("MetaData context is not mutable: " + retrieval + " for " + context.toShortString());
| return;
| }
|
| updateMetaData(repository, context, mutable, true);
| }
|
while we do a lookup with the scope key:
| public MetaData getMetaData()
| {
| if (repository == null)
| return null;
|
| return repository.getMetaData(getScope());
| }
|
In kernel module we go over KernelMetaDataRepository::getMetaData(ControllerContext),
which does similar + a bit more:
| public MetaData getMetaData(ControllerContext context)
| {
| MutableMetaDataRepository repository = getMetaDataRepository();
| ScopeKey scope = context.getScopeInfo().getScope();
| MetaData metaData = repository.getMetaData(scope);
| if (metaData == null)
| {
| initMetaDataRetrieval(context);
| metaData = repository.getMetaData(scope);
| if (metaData == null)
| throw new IllegalStateException("Error initialising metadata state: " + scope);
| }
| return metaData;
| }
|
| // THE MISSING PIECE
| protected MetaDataRetrieval initMetaDataRetrieval(ControllerContext context)
| {
| MutableMetaDataRepository repository = getMetaDataRepository();
| ScopeInfo scopeInfo = context.getScopeInfo();
| return scopeInfo.initMetaDataRetrieval(repository, context);
| }
|
I guess it's the "missing piece" that makes ScopeInfo::getMetaData work for Kernel - by luck. :-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267323#4267323
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267323
14 years, 5 months
[jBPM Development] - Re: Confused about versioning
by mauromol
Sorry for taking again this discussion, but I still need some clarification.
Given that the addition of PARENTLOCKMODE column mentioned in my previous message seems to have been reverted in 3.2.5.SP5 (as of https://jira.jboss.org/jira/browse/JBPM-2119), it's still not clear to me what should be the upgrade direction to follow.
I'm now using jBPM 3.3.0 GA and I see that a 3.3.1 GA is available.
But I see that a 3.2.6.SP1 is available too, and 3.2.6.SP1 is newer than 3.3.1 GA.
Now, I would need the fix for https://jira.jboss.org/jira/browse/JBPM-2036, which should be fixed in 3.2.6.SP1. Moreover, you suggest to upgrade from 3.3.1 to 3.2.6.SP1, which has to be considered the successor of 3.3.1.
>From this I understand that I should upgrade from 3.3.0GA to 3.2.6.SP1.
However... what's next?
In JIRA, I see:
- a planned 3.3.2, "formerly known as 3.2.7", which I suppose should be the successor of 3.2.6.SP1?
- a planned 3.2.9, for which I can't understand the collocation
Given that I don't need the GWT console and that I would like to keep on the more recent version of jBPM 3, which upgrade path should I follow?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267318#4267318
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267318
14 years, 5 months