[Design of Messaging on JBoss (Messaging/JBoss)] - Remoting refactoring complete
by timfox
At long last I have completed the refactoring of our remoting layer.
Now we have a 100% generic shiny clean remoting abstraction into which is it's easy to plug any transport provide e.g. MINA or Netty.
The layer has no dependencies on MINA. It was quite painful uncoupling some of our tightly coupled code. The end result is a much cleaner abstraction.
As previously mentioned I have created an spi package. Any new provider is easily integrated by making an implemention of the AcceptorFactory, Acceptor, ConnectorFactory, Connector and Conection. The implementions of these are typically very thin since, as I say, I have moved all the generic code into our generic classes.
Along the way I've been able to simplify and get rid of other stuff like ConnectionManager which is no longer necessary.
Once the spi interfaces have been implemented, you need to register to the AcceptorFactory and ConnectorFactory with remoting otherwise it won't know about the transport.
There are methods on ConnectionRegistry and RemotingService to register these programmatically. Or you can specify acceptor factories in the remoting config.
On the client side, connector factories are specified by default in a file jbm-connector-factories.properties which is in the jar or can be overridden with another copy of that file on the classpath.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167132#4167132
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167132
16 years, 7 months
[Design of JBoss Transaction Services] - Re: JBAS-5801 - Locking in 2PC
by adrian＠jboss.org
"jhalliday" wrote : yes, blocking end() should eliminate the race, at the cost of the rollback no longer actually 'killing' a long running operation.
|
Ok that's what I'm doing. Maybe I should change the try-lock to have
a default value. Blocking forever is never a good idea.
anonymous wrote :
| My concern with actually interrupting the business logic operation is related to the way connections are multiplexed. You may have one or more logical connections on a single TCP/IP connection. Killing the network level one may therefore kill unrelated business operations in other threads. Depending how the multiplexing is implemented by the driver, interrupting a logical connection handle may mess up the multiplexing, with much the same undesirable side effects. Potentially you have to throw away the entire connection pool, not just a single logical connection if you want to be safe.
|
No , I'm talking about doing ManagedConnection.destroy()
effectively invoke close() on all the physical connections
that are part of the timed out transaction and where the connection-factory
has been configured for this behaviour due to known or suspected
broken/hanging drivers.
Whether the underlying driver actually honours the request or is
mulitplexing underneath is another question.
It's just further option to try to recover from broken/blocking
connections causing timeouts.
Whether you also interrupt() the thread is a different issue,
since in most cases a close() - MSSQL aside - should be allowed to proceed
even with other concurrent requests.
anonymous wrote :
| Add to that the fact that the XA control messages probably flow over the same TCP/IP connection and you wind up with a problem. Sure, presumed rollback means that the resource manager should abort the tx when the TCP/IP connection drops, but some (db2?) don't. You need to keep the connection intact if you want to be sure it gets terminated cleanly, or rely on the crash recovery to tidy it up.
Yes, Oracle is the same for local transactions. If you crash the connection it rolls back
when auto-commit=false. If you explicitly close it without committing,
it commits anyway - so much for auto-commit=false :-(
So you have to do a rollback() before closing(), just to be sure.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167125#4167125
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167125
16 years, 7 months
[Design of JBoss Web Services] - JBoss 5.0.CR1 and JSF Error
by poss
I have a deployed war that works perfectly well on 4.2.2.
Using the defaults, I get all kinds of errors when I start up on
JBOss 5.0.cr1.
Does anyone have any idea what I can do to fix this?
Thanks
Here is the error:
====================================================================
2008-07-25 11:47:42,819 INFO [org.jboss.web.WebService:createService] Using RMI server codebase: http://127.0.0.1:8083/
2008-07-25 11:47:53,088 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController:incrementState] Error installing to Parse: name=vfszip:/home/Desktop/jboss5/jboss-5.0.0.CR1/server/Picasso/deploy/Picasso.war state=Not Installed mode=Manual requiredState=Parse
org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfszip:/home/Desktop/jboss5/jboss-5.0.0.CR1/server/Picasso/deploy/Picasso.war
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:343)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:303)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:275)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.deploy(AbstractParsingDeployerWithOutput.java:236)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:174)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:970)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:911)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1392)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:784)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:912)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:834)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:672)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:455)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:594)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:257)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:135)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:409)
at org.jboss.Main.boot(Main.java:209)
at org.jboss.Main$1.run(Main.java:544)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: Failed to parse schema for nsURI=http://java.sun.com/JSF/Configuration, baseURI=null, schemaLocation=http://java.sun.com/dtd/web-facesconfig_1_1.dtd
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)
at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:168)
at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:198)
at org.jboss.deployers.vfs.spi.deployer.JBossXBDeployerHelper.parse(JBossXBDeployerHelper.java:170)
at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:132)
at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:118)
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:185)
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:336)
... 21 more
Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to parse schema for nsURI=http://java.sun.com/JSF/Configuration, baseURI=null, schemaLocation=http://java.sun.com/dtd/web-facesconfig_1_1.dtd
at org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver.resolve(DefaultSchemaResolver.java:340)
at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:302)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:401)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source)
at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:199)
... 28 more
Caused by: org.jboss.xb.binding.JBossXBRuntimeException: -1:-1 25:3 The markup in the document preceding the root element must be well-formed.
at org.jboss.xb.binding.sunday.unmarshalling.XsdBinderTerminatingErrorHandler.handleError(XsdBinderTerminatingErrorHandler.java:40)
at org.apache.xerces.impl.xs.XMLSchemaLoader.reportDOMFatalError(Unknown Source)
at org.apache.xerces.impl.xs.XSLoaderImpl.load(Unknown Source)
at org.jboss.xb.binding.Util.loadSchema(Util.java:395)
at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:175)
at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:146)
at org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver.resolve(DefaultSchemaResolver.java:332)
===========================================================
Do I have to modify my configuration somewhere?
Any help would be appreciated.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167116#4167116
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167116
16 years, 7 months
[Design of JBoss Transaction Services] - Re: JBAS-5801 - Locking in 2PC
by jhalliday
yes, blocking end() should eliminate the race, at the cost of the rollback no longer actually 'killing' a long running operation.
My concern with actually interrupting the business logic operation is related to the way connections are multiplexed. You may have one or more logical connections on a single TCP/IP connection. Killing the network level one may therefore kill unrelated business operations in other threads. Depending how the multiplexing is implemented by the driver, interrupting a logical connection handle may mess up the multiplexing, with much the same undesirable side effects. Potentially you have to throw away the entire connection pool, not just a single logical connection if you want to be safe.
Add to that the fact that the XA control messages probably flow over the same TCP/IP connection and you wind up with a problem. Sure, presumed rollback means that the resource manager should abort the tx when the TCP/IP connection drops, but some (db2?) don't. You need to keep the connection intact if you want to be sure it gets terminated cleanly, or rely on the crash recovery to tidy it up.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167107#4167107
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167107
16 years, 7 months