[Design of POJO Server] - Re: Minimal now boots
by adrian＠jboss.org
The default bootstrap is clean now.
There is one DEBUG message I'm going to look at during shutdown:
| 2006-09-18 15:52:19,939 DEBUG [org.jboss.system.ServiceController] destroying service: jboss.management.local:type=JSR88DeploymentManager,name=DefaultManager
| 2006-09-18 15:52:19,953 DEBUG [org.jboss.system.ServiceController] Ignoring destroy request for service: jboss.management.local:type=JSR88DeploymentManager,name=DefaultManager at state DESTROYED
| 2006-09-18 15:52:19,953 DEBUG [org.jboss.system.ServiceController] removing service: jboss.management.local:type=JSR88DeploymentManager,name=DefaultManager
| 2006-09-18 15:52:19,954 DEBUG [org.jboss.system.ServiceCreator] Removing mbean from server: jboss.management.local:type=JSR88DeploymentManager,name=DefaultManager
| 2006-09-18 15:52:19,958 DEBUG [org.jboss.system.ServiceCreator] Error unregistering mbean jboss.management.local:type=JSR88DeploymentManager,name=DefaultManager
| javax.management.InstanceNotFoundException: jboss.management.local:type=JSR88DeploymentManager,name=DefaultManager is not registered.
| at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:527)
| at org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:383)
| at org.jboss.system.ServiceCreator.uninstall(ServiceCreator.java:309)
| at org.jboss.system.microcontainer.InstantiateAction.uninstallAction(InstantiateAction.java:53)
| at org.jboss.system.microcontainer.ServiceControllerContextAction.uninstall(ServiceControllerContextAction.java:90)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
| at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:236)
| at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:723)
| at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:685)
| at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:613)
| at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:223)
| at org.jboss.system.ServiceController.safelyRemoveAnyRegisteredContext(ServiceController.java:733)
| at org.jboss.system.ServiceController.remove(ServiceController.java:549)
| at org.jboss.system.deployers.ServiceDeployer.remove(ServiceDeployer.java:154)
| at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:112)
| at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:43)
| at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.undeploy(AbstractSimpleRealDeployer.java:63)
| at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.prepareUndeploy(AbstractSimpleDeployer.java:42)
| at org.jboss.deployers.plugins.deployer.DeployerWrapper.prepareUndeploy(DeployerWrapper.java:105)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:375)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:384)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:322)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.shutdown(MainDeployerImpl.java:438)
| at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:776)
| at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:758)
| at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.run(ServerImpl.java:743)
|
But this is probably somebody going around the ServiceController
to unregister the MBean?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972317#3972317
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972317
19 years, 6 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Can the transaction manager retry commit or rollback?
by mark.little＠jboss.com
"timfox" wrote : On a related issue, if the commit succeeds in the JBM resource, but some failure occurs e.g. network failure before the invocation returns to the transaction manager, so the tx mgr gets an exception and thinks the commit failed.
|
| So it retries the commit, but there is no record of the tx in the JBM resource since it committed ok and was removed as far as it was concerned.
|
| How should we deal with this? Should we always return success if a commit comes in for a transction we don't know about? Is this safe?
It's complex ;-)
In order to receive a commit from the TM, the resource obviously had to return VoteCommit during prepare. If the resource subsequently decided to change that decision then we're in the realms of heuristics and the resource has to remember that decision durably and respond appropriately during commit.
Unfortunately just because this resource returns VoteCommit in prepare, doesn't mean that all of the participants in the transaction will do so. It could be told to rollback. In that case, it obviously won't receive a commit message from the TM at any point, so we're alright here.
So if it receives a commit and there's no information in the log, it could return committed, on the assumption that the TM will only be sending commit for participants it remembers were associated with this transaction. Usually a good assumption ;-)
There is one wrinkle in this, which if you're a good resource implementation won't show up anyway: if commit fails and you send back HeuristicMixed/Hazard/Rollback (depending on the failure type) and then cleanup, you would be giving the wrong answer next time commit comes in. However, if a heuristic decision happens, you really should remember that *before* replying to the TM and keep the information around until it is resolved.
BTW, I'm assuming we're talking about the case where there has been a previous prepare call, i.e., in 2PC with NO one-phase commit optimisation.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972303#3972303
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972303
19 years, 6 months
[Design of POJO Server] - Re: ENC Deployment
by adrian＠jboss.org
"bill.burke(a)jboss.com" wrote :
| That's nice for basic beans, but as I showed before, it is just not so simple for Java EE land where the ENC -> Global JNDI binding cannot be determine by the available metadata. To put it in other terms, the available metadata may not be enough to construct a Kernel identity or exact JNDI binding. The referenced component will need to be searched for based on the position of the component in the deployment and based on the little of metadata that was made available by the application developer.
Whatever mechanism is used needs to be validatable via a "dry run"
through the deployers.
i.e. It should be possible to create a profile (list of deployments)
and then say "does it make sense?", "what is missing/unresolved?", etc.
If that is not possible then the modal is broken.
Implicit rules like "position in the file" are supportable but
inherently prone to error/breakage when the file is changed.
e.g. a conflicting definition is interpolated
or the order is changed by some user/tool/ide that doesn't understand
the importance.
But that's not my problem. :-)
I've always hated such "scripting" as being brittle.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972302#3972302
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972302
19 years, 6 months
[Design of POJO Server] - Re: ENC Deployment
by bill.burke＠jboss.com
"adrian(a)jboss.org" wrote : The next step is what the ENC deployer does about the
| dependencies.
|
| e.g. If I want a DataSource, the DataSource should be deployed
| before I start.
|
| The way this should work is that the object that wants an ENC
| should be deployed through the Controller, either as a POJO
| or JMX with the relevant dependency:
|
|
| | <bean name="MyEJB">
| | <property name="enc">
| | <inject bean="MyEJB,ENCFactory" property="enc"/>
| | </property>
| | etc.
| |
|
| The ENC deployer creates the ENCFactory using the metadata
| from the scope it was provided with.
That's nice for basic beans, but as I showed before, it is just not so simple for Java EE land where the ENC -> Global JNDI binding cannot be determine by the available metadata. To put it in other terms, the available metadata may not be enough to construct a Kernel identity or exact JNDI binding. The referenced component will need to be searched for based on the position of the component in the deployment and based on the little of metadata that was made available by the application developer.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972296#3972296
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972296
19 years, 6 months
[Design of POJO Server] - Re: ENC Deployment
by bill.burke＠jboss.com
"adrian(a)jboss.org" wrote : The major work is how in the ENC is constructed.
| Obviously there will be an ENC deployer.
|
| This needs to collect all the metadata to populate the ENC structure:
| 1) From the spec defined xml
| 2) From override xml
| 3) From annotations on the class(es)
| 4) From the metadata itself (e.g. instance overrides)
|
| In my opinion, it is best that the ENC Deployer just does step 4.
| Steps 1-3 should be done by the earlier parsers that know
| what to look at, e.g. the ejb, web and client deployers
|
| If these populate the MetaData hierarchy (converting xml into
| annotations) the ENC deployer just needs to know the ScopeKey
| and collect all the annotations.
I think we talked about this before...
These need to be the steps:
1) A registration phase for all deployments
2) Analyzation of XMLs, annotations and metadata to determine dependencies.
This step is partially complex as bindings can be determined by both the classtype of the component and position in the deployment (is the referenced component in the EJB-JAR? No? The EAR? No? Globally?)
3) Register dependencies with controller
4) Start and populate ENC and do any injections.
I do this in the current J2EE injection/XML processing. Within this phase I create two different objects. One object is an ENCInjector object. This object gets registered with Container and executed at component startup. If there are any injections to be done, these are registered with the container using a different object, an Injector. Injectors inject into object instances and are keyed based on classtype.
For EJB Containers there can be multiple class types that have injectors. The BeanClass itself, and any interceptor classes.
For Web Containers, you have servlet classes, filter classes, context listener classes, and I believe, taglib classes. The Web tier has the additional problem of JSP classes which are not available at deployment time or may be changed on the fly.
I have created an abstraction so that the ENC/Injection Handlers are shared between the EJB and Web tiers
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972287#3972287
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972287
19 years, 6 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Can the transaction manager retry commit or rollback?
by mark.little＠jboss.com
"adrian(a)jboss.org" wrote : I'm not implementing a TM, I'm implementing an heuristic resource
| with a local branch log.
|
| JMS is a remote resource.
|
OK, with you now.
anonymous wrote :
| e.g.
| If a JBossMessaging server gets enlisted by a transaction manager
| on a machine that explodes and the log is lost then you need
| a mechanism to put the messages back in the queue.
|
| The exploded tm is never going to recover. :-)
|
I'm sure if you ask an IBM sales-bod they've got a solution for this too ;-) It's just "sometime in 2010"!
anonymous wrote :
| There are other reasons why the TM might not complete
| the transaction (e.g. network outage) and you need to get
| the messages processed even if it means an heuristic.
|
| Its the same issue as when you need to clear db locks
| when a server crashes holding the locks and it can't be recovered.
Agreed. Though as ever I'd warn against over-use of heuristics to "solve" the problem. It's often a too-easy cop-out. Not saying it is in this case, but just a general warning.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972285#3972285
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972285
19 years, 6 months