[Design of JCA on JBoss] - JCA deployment on JBOSS 4.0.0
by tpawankumar
Hi All,
I am trying to deploy JCA for infranet on JBOSS4.0.0. I have kept the files ra.xml and infranet-ds.xml files under META-INF and created rar file and deployed in server/all/deploy folder.
Following are the two files
infranet-ds.xml
<?xml version="1.0" encoding="UTF-8"?>
<connection-factories>
<tx-connection-factory>
<jndi-name>Ombi.Infranet</jndi-name>
<rar-name>infranetconnector.rar</rar-name>
<connection-definition>
javax.resource.cci.ConnectionFactory
</connection-definition>
</tx-connection-factory>
</connection-factories>
ra.xml
<?xml version="1.0" encoding="UTF-8"?>
<connector id="Connector_ID" version="1.5" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd">
<display-name>InfranetConnector</display-name>
<vendor-name>Covad</vendor-name>
<eis-type>Infranet</eis-type>
<resourceadapter-version>1.0</resourceadapter-version>
<resourceadapter-class>
org.jboss.resource.deployment.DummyResourceAdapter
</resourceadapter-class>
<outbound-resourceadapter>
<connection-definition>
<managedconnectionfactory-class>com.covad.billing.framework.connector.InfLocalTxManagedConnectionFactory</managedconnectionfactory-class>
<config-property>
<config-property-name>BrandSwitch</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>switch</config-property-value>
</config-property>
<connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface>
<connectionfactory-impl-class>com.covad.billing.framework.connector.InfConnectionFactory</connectionfactory-impl-class>
<connection-interface>javax.resource.cci.Connection</connection-interface>
<connection-impl-class>
com.covad.billing.framework.connector.InfCciConnection
</connection-impl-class>
</connection-definition>
<transaction-support>LocalTransaction</transaction-support>
<authentication-mechanism>
<authentication-mechanism-type>BasicPassword</authentication-mechanism-type>
<credential-interface>javax.resource.spi.security.PasswordCredential</credential-interface>
</authentication-mechanism>
<reauthentication-support>false</reauthentication-support>
</outbound-resourceadapter>
Following is the error displayed when i deployed :
Stack Trace on JBOSS console
16:35:02,952 INFO [EARDeployer] Init J2EE application: file:/E:/jboss-4.0.0[1]/jboss-4.0.0/server/a
ll/deploy/omBilling.ear
16:35:06,999 INFO [EjbModule] Deploying OMBillingInterface
16:35:07,046 INFO [EJBDeployer] Deployed: file:/E:/jboss-4.0.0[1]/jboss-4.0.0/server/all/tmp/deploy
/tmp22403omBilling.ear-contents/omBilling.jar
16:35:07,077 INFO [EARDeployer] Started J2EE application: file:/E:/jboss-4.0.0[1]/jboss-4.0.0/serve
r/all/deploy/omBilling.ear
16:35:07,187 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
MBeans waiting for other MBeans:
ObjectName: jboss.jca:service=TxCM,name=Ombi.Infranet
state: CONFIGURED
I Depend On: jboss.jca:service=ManagedConnectionPool,name=Ombi.Infranet
jboss.jca:service=CachedConnectionManager
jboss:service=TransactionManager
Depends On Me: jboss.jca:service=ConnectionFactoryBinding,name=Ombi.Infranet
ObjectName: jboss.jca:service=ManagedConnectionPool,name=Ombi.Infranet
state: CONFIGURED
I Depend On: jboss.jca:service=ManagedConnectionFactory,name=Ombi.Infranet
Depends On Me: jboss.jca:service=TxCM,name=Ombi.Infranet
ObjectName: jboss.jca:service=ManagedConnectionFactory,name=Ombi.Infranet
state: CONFIGURED
I Depend On: jboss.jca:service=RARDeployment,name='infranetconnector.rar'
Depends On Me: jboss.jca:service=ManagedConnectionPool,name=Ombi.Infranet
ObjectName: jboss.jca:service=ConnectionFactoryBinding,name=Ombi.Infranet
state: CONFIGURED
I Depend On: jboss.jca:service=TxCM,name=Ombi.Infranet
Depends On Me:
MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM:
ObjectName: jboss.jca:service=RARDeployment,name='infranetconnector.rar'
state: NOTYETINSTALLED
I Depend On:
Depends On Me: jboss.jca:service=ManagedConnectionFactory,name=Ombi.Infranet
Please guide me if anything needs to be modified in xml files.Please help me this is very urgent your help will be appreciated.
thanks in advance
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066890#4066890
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066890
16 years, 9 months
[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4574 and JBAS-1476
by bstansberry＠jboss.com
I'm not going to get into any issues related to SFSBs, etc., as my understanding of the issue from the customer test Ben showed me is that it was related to caching of the HA-JNDI proxy in the static org.jnp.interfaces.NamingContext.haServers map. If there's more to it beyond that, I'll let Ben comment.
I have simple unit test that shows the issue. I haven't checked it in this evening because the test deploys an instance of org.jboss.naming.NamingService and I'm concerned that might screw up the AS in some way.
But, here's essentially what the test does:
| Properties env = new Properties();
| env.setProperty("java.naming.provider.url", namingURL);
|
| Context ctx1 = new InitialContext(env);
| assertEquals("VALUE", ctx1.lookup("NamingRestartBinding"));
|
| // HOLD ONTO REF to ctx1 so the weak ref to it's Naming stub does
| // not get gc'ed from static map in org.jnp.interfaces.NamingContext.
|
| // Redeploy the local and HA naming services
| redeploy("naming-restart.sar");
|
| Context ctx2 = new InitialContext(env);
| try
| {
| // This lookup will fail
| assertEquals(ObjectBinder.VALUE, ctx2.lookup(ObjectBinder.NAME));
| }
| catch (NamingException e)
| {
| log.error("Caught NamingException", e);
| fail(e.getMessage());
| }
The test deploys both an alternate local JNDI and an alternate HA-JNDI. (I figure bouncing the real services is not very friendly to other tests ;) ) The test fails when I test against the HA-JNDI service; passes with regular JNDI.
When I look into it in detail, the failure mode is clear. The lookup by ctx1 results in a naming proxy being cached. Server is restarted, so the RMI stub in the cached proxy no longer matches the one exported by the server. When ctx2 does a lookup, the cached proxy is used and the call fails with "java.rmi.NoSuchObjectException: no such object in table". I see no indication the failure has nothing at all to do with the correctness or incorrectness of the the viewId.
If I let the test continue after the failure and do another lookup with ctx2, it succeeds, since the failure flushes the stale proxy out of the haServers cache.
The interesting thing is the test passes with regular JNDI. Not sure at this point why. In both cases the call uses RMI. With regular JNDI a simple RMI stub is used; with HA-JNDI the RMI stub is encapsulated in an HARMIClient.
Part of the problem here is the use of RMI for the HA-JNDI transport. If Remoting's socket transport were used, bouncing the server would not invalidate the client-side InvokerLocator.
[OT] Re: 'the "view change" is less than it previously was" after a cluster restart. No. The viewId passed between the server and HA clients is not a counter. It is a hash of the service's cluster topology.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066876#4066876
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066876
16 years, 9 months
[Design of JBossCache] - Re: Region management issues
by bstansberry＠jboss.com
The high level conceptual issue is we have one class for Region (IMO good). But, Region has 4 different use cases: 1) eviction, 2) marshalling/classloading, 3) region activation/inactivation and 4) PojoCache reference scoping. Marshalling and activation/inactivation are related, but there isn't a 100% conceptual overlap. Region activation/inactivation is also usable as a way to get partial state transfer, even if there are no classloader issues involved.
In 2.0 we deal with the different use cases by sometimes passing a Region.Type into the getRegion() method. We scan through all registered regions looking for Fqn matches. Then based on the requested type, we check characteristics of the regions to see if they match. The code block in my first post shows that.
Two problems with this:
1) Somewhat inefficient, since if we're looking for eviction region /a and there's marshalling region /a/b/c, we do a map lookup for /a/b/c, reject the marshalling region, then do a map lookup for /a/b (miss) and then finally do a map lookup for /a and get our eviction region. Seems more efficient to do a map lookup for /a/b/c, and then call getParent() on the region until we find an eviction region.
2) If we request a marshalling region, the current algorithm returns null if there is no region with a classloader registered. That's a new behavior added in 2.0; didn't work that way in 1.x. In 1.x you could create a "marshalling" region and never register a classloader. That's why you had to add a region registration to the unit test.
The second problem can be solved without doing the nested region thing I've suggested on this thread. You just change getRegion such that if Region.Type.MARSHALLING is passed, you keep a ref to the lowest region you find. You then keep looking for one with a classloader registered. If you find one with a classloader, return it. If not, return the first one you found.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066730#4066730
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066730
16 years, 9 months