[JBoss Cache: Core Edition] - Re: Far cache problem (3.0.2) tx problems
by rs1050
I tried using latest 3.0.3 snapshot (from Jan 27) - same problem.
I am using resin.
Here is the code (cleanup a bit for readability) from the class UserMangerImpl:
UserTransaction utx= null;
Context context = new InitialContext();
utx = (UserTransaction) context.lookup("java:comp/UserTransaction");
logger.info("user TX before start of TX: "+utx+", status: "+utx.getStatus());
utx.begin();
logger.info("started user TX: "+utx+", status: "+utx.getStatus());
try {
//update cache here
//update db here
//throw dummy exception here
throw new RuntimeException("test");
logger.info("committing tx");
utx.commit();
} catch (Exception e) {
logger.info("rolling back tx");
utx.rollback();
}
logger.info("User TX:"+utx+", status: "+utx.getStatus());
Here is relevant output (app output removed):
14:58:33,461 [http--8080-0$20568209] INFO UserManagerImpl:updateUser:58 - user TX before start of TX: UserTransactionProxy[], status: 6
14:58:33,463 [http--8080-0$20568209] INFO UserManagerImpl:updateUser:63 - started user TX: UserTransactionProxy[], status: 0
14:58:33,463 [http--8080-0$20568209] DEBUG NearCacheImpl:setValue:53 - setting value for object:/user/1:86 in cacheId:3
14:58:33,465 [http--8080-0$20568209] INFO TMCacheListener:onNodeTransactionregistered:29 - : EventImpl{type=TRANSACTION_REGISTERED,pre=false, cache=org.jboss.cache.DataContainerImpl [2 nodes, 0 locks], modificationType=null, data=null, fqn=null, transaction=Transaction[01:730c2f36], originLocal=true, targetFqn=null, successful=false, newView=null, buddyGroup=null}
14:58:33,476 [http--8080-0$20568209] INFO TMCacheListener:onNodeEvent:41 - : EventImpl{type=NODE_MODIFIED,pre=true, cache=org.jboss.cache.DataContainerImpl [2 nodes, 0 locks], modificationType=PUT_DATA, data={d=TMUserImpl{_id=1:86, _username='asdf', _SLUsername='', _password='sdf{salt}', _email='asdf(a)xomc.om233', _userStateCd=A}}, fqn=/user/1:86, transaction=Transaction[01:730c2f36], originLocal=true, targetFqn=null, successful=false, newView=null, buddyGroup=null}
14:58:33,492 [http--8080-0$20568209] INFO TMCacheListener:onNodeEvent:41 - : EventImpl{type=NODE_MODIFIED,pre=false, cache=org.jboss.cache.DataContainerImpl [2 nodes, 0 locks], modificationType=PUT_DATA, data={d=TMUserImpl{_id=1:86, _username='asdf', _SLUsername='', _password='sdf{salt}', _email='asdf(a)xomc.om233', _userStateCd=A}}, fqn=/user/1:86, transaction=Transaction[01:730c2f36], originLocal=true, targetFqn=null, successful=false, newView=null, buddyGroup=null}
14:58:33,572 [http--8080-0$20568209] INFO UserManagerImpl:updateUser:95 - rolling back tx
14:58:33,574 [http--8080-0$20568209] INFO TMCacheListener:onNodeTransactioncompleted:24 - : EventImpl{type=TRANSACTION_COMPLETED,pre=false, cache=org.jboss.cache.DataContainerImpl [2 nodes, 0 locks], modificationType=null, data=null, fqn=null, transaction=Transaction[], originLocal=true, targetFqn=null, successful=false, newView=null, buddyGroup=null}
14:58:33,612 [http--8080-0$20568209] INFO UserManagerImpl:updateUser:103 - User TX: UserTransactionProxy[], status: 6
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206063#4206063
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206063
17 years
[Remoting] - Re: Remoting2 - MC bean for SSL Connector
by jaikiran
Ron, thanks a lot for those pointers. With that help, i was able to come up with a configuration which deploys the ssl connector for EJB3. Here's the configuration:
<?xml version="1.0" encoding="UTF-8"?>
|
| <!--
|
| EJB3 SSL Connector
|
| -->
|
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
|
| <!-- We have to expose this MC bean through JMX http://www.jboss.com/index.html?module=bb&op=viewtopic&t=149570#4206018 -->
| <bean name="DomainServerSocketFactoryService" class="org.jboss.remoting.security.domain.DomainServerSocketFactoryService">
| <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.remoting:service=ServerSocketFactory,type=SecurityDomainAdvanced",exposedInterface=org.jboss.remoting.security.domain.DomainServerSocketFactoryServiceMBean.class,registerDirectly=true)</annotation>
|
| <property name="securityDomain">java:/jaas/SSLAdvanced</property>
| <depends>JaasSecurityDomain</depends>
| </bean>
|
| <!-- This is the MC bean which sets the keystore url and password -->
| <bean name="JaasSecurityDomain" class="org.jboss.security.plugins.JaasSecurityDomain">
| <constructor>
| <parameter>SSLAdvanced</parameter>
| </constructor>
| <property name="keyStoreURL">localhost.keystore</property>
| <property name="keyStorePass">opensource</property>
|
| </bean>
|
| <!-- The serverConfiguration that we will use in our EJB3SSLRemotingConnector.
| This serverConfiguration will define the (usual) invocationHandler(s) and also the serverParameters.
| The serverParameter is important since that's the place where we specify the serverSocketFactory to use for SSL -->
| <bean name="SSLServerConfiguration" class="org.jboss.remoting.ServerConfiguration">
| <property name="invocationHandlers">
| <map keyClass="java.lang.String" valueClass="java.lang.String">
| <entry>
| <key>AOP</key>
| <value>
| org.jboss.aspects.remoting.AOPRemotingInvocationHandler
| </value>
| </entry>
| </map>
| </property>
| <property name="serverParameters">
| <map keyClass="java.lang.String" valueClass="java.lang.Object">
| <entry>
| <key>serverSocketFactory</key>
| <!-- This value should match the JMX MBean that we create above for the MC Bean "DomainServerSocketFactoryService" -->
| <value>jboss.remoting:service=ServerSocketFactory,type=SecurityDomainAdvanced</value>
| </entry>
| </map>
| </property>
|
|
| </bean>
|
| <!-- Our EJB3 SSL Remoting connector which uses the SSLServerConfiguration that we created above. It also
| configures the invokerLocator -->
| <bean name="EJB3SSLRemotingConnector" class="org.jboss.remoting.transport.Connector">
|
| <property name="invokerLocator">
|
| <value-factory bean="ServiceBindingManager"
| method="getStringBinding">
| <parameter>
| jboss.remoting:type=Connector,name=SSLEjb3Connector,handler=ejb3
| </parameter>
| <parameter>
| <null />
| </parameter>
| <parameter>sslsocket://${jboss.bind.address}:${port}</parameter>
| <parameter>
| <null />
| </parameter>
| <parameter>3843</parameter>
| </value-factory>
|
| </property>
| <property name="serverConfiguration">
| <inject bean="SSLServerConfiguration" />
| </property>
| </bean>
|
| </deployment>
This deploys fine or rather with a single ERROR message which at first seemed harmless to me:
| 2009-01-31 16:08:34,313 ERROR [org.jboss.remoting.transport.socket.SocketServerInvoker] (AcceptorThread[[SSL: ServerSocket[addr=/0.0.0.0,port=0,localport=3843]]]) SSLServerSocket error
| javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
| at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
| at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
| at org.jboss.remoting.util.SecurityUtility.accept(SecurityUtility.java:931)
| at org.jboss.remoting.transport.socket.SocketServerInvoker$AcceptThread.run(SocketServerInvoker.java:1003)
However when i run the SSL client to lookup a bean through sslsocket, the client just hangs. A bit of debugging through logs indicates a couple of issues in Remoting code:
1) With the above configuration, the server.log shows me this:
2009-01-31 16:39:10,996 DEBUG [org.jboss.security.plugins.JaasSecurityDomain] (HDScanner) Using KeyStore=vfszip:/opt/jpai/jboss-5.0.0.GA/server/default/deploy/jboss-ejb3-tutorial-ssl.jar/localhost.keystore
| 2009-01-31 16:39:10,996 DEBUG [org.jboss.security.plugins.JaasSecurityDomain] (HDScanner) Creating JaasSecurityDomain(SSLAdvanced)
| 2009-01-31 16:39:10,996 DEBUG [org.jboss.security.plugins.JaasSecurityDomain] (HDScanner) Created JaasSecurityDomain(SSLAdvanced)
| 2009-01-31 16:39:10,996 DEBUG [org.jboss.system.ServiceController] (HDScanner) Creating service jboss.remoting:service=ServerSocketFactory,type=SecurityDomainAdvanced
| 2009-01-31 16:39:10,997 DEBUG [org.jboss.security.plugins.JaasSecurityDomain] (HDScanner) Starting JaasSecurityDomain(SSLAdvanced)
| 2009-01-31 16:39:11,309 DEBUG [org.jboss.security.plugins.JaasSecurityManagerService] (HDScanner) Added SSLAdvanced, org.jboss.security.plugins.JaasSecurityDomain@1caef1c to map
| 2009-01-31 16:39:11,314 DEBUG [org.jboss.security.plugins.auth.JaasSecurityManagerBase.SSLAdvanced] (HDScanner) CachePolicy set to: org.jboss.util.TimedCachePolicy@177533f
| 2009-01-31 16:39:11,314 DEBUG [org.jboss.security.plugins.JaasSecurityManagerService] (HDScanner) setCachePolicy, c=org.jboss.util.TimedCachePolicy@177533f
| 2009-01-31 16:39:11,314 DEBUG [org.jboss.security.integration.JNDIBasedSecurityManagement] (HDScanner) Creating SDC for domain=SSLAdvanced
| 2009-01-31 16:39:11,315 DEBUG [org.jboss.security.plugins.auth.JaasSecurityManagerBase.SSLAdvanced] (HDScanner) CallbackHandler: org.jboss.security.auth.callback.JBossCallbackHandler@fa874b
| 2009-01-31 16:39:11,315 DEBUG [org.jboss.security.plugins.auth.JaasSecurityManagerBase.SSLAdvanced] (HDScanner) CachePolicy set to: org.jboss.util.TimedCachePolicy@1c87675
| 2009-01-31 16:39:11,315 DEBUG [org.jboss.security.integration.JNDIBasedSecurityManagement] (HDScanner) setCachePolicy, c=org.jboss.util.TimedCachePolicy@1c87675
| 2009-01-31 16:39:11,316 DEBUG [org.jboss.security.plugins.JaasSecurityDomain] (HDScanner) Started JaasSecurityDomain(SSLAdvanced)
| 2009-01-31 16:39:11,328 DEBUG [org.jboss.system.ServiceController] (HDScanner) starting service jboss.remoting:service=ServerSocketFactory,type=SecurityDomainAdvanced
| 2009-01-31 16:39:11,351 DEBUG [org.jboss.remoting.ServerInvoker] (HDScanner) SocketServerInvoker[0.0.0.0:3843] did not find server socket factory configuration as mbean service or classname. Creating default server socket factory.
| 2009-01-31 16:39:11,420 DEBUG [org.jboss.remoting.ServerInvoker] (HDScanner) SocketServerInvoker[0.0.0.0:3843] created server socket factory com.sun.net.ssl.internal.ssl.SSLServerSocketFactoryImpl@260627
| 2009-01-31 16:39:11,421 DEBUG [org.jboss.remoting.transport.Connector] (HDScanner) Handler supplied is not an object name.
| 2009-01-31 16:39:11,421 DEBUG [org.jboss.remoting.ServerInvoker] (HDScanner) SocketServerInvoker[jaikiran.jboss:3843] added org.jboss.aspects.remoting.AOPRemotingInvocationHandler@5e1bc1 for subsystem 'AOP'
| 2009-01-31 16:39:11,421 DEBUG [org.jboss.remoting.transport.socket.SocketServerInvoker] (HDScanner) SocketServerInvoker[jaikiran.jboss:3843] starting
| 2009-01-31 16:39:11,529 DEBUG [org.jboss.remoting.transport.socket.SocketServerInvoker] (HDScanner) SocketServerInvoker[jaikiran.jboss:3843] created [SSL: ServerSocket[addr=/0.0.0.0,port=0,localport=3843]]
| 2009-01-31 16:39:11,529 DEBUG [org.jboss.remoting.ServerInvoker] (HDScanner) SocketServerInvoker[jaikiran.jboss:3843] started for locator InvokerLocator [sslsocket://jaikiran.jboss:3843/?]
| 2009-01-31 16:39:11,529 DEBUG [org.jboss.remoting.transport.socket.SocketServerInvoker] (HDScanner) SocketServerInvoker[jaikiran.jboss:3843] started
| 2009-01-31 16:39:11,529 DEBUG [org.jboss.remoting.transport.Connector] (HDScanner) org.jboss.remoting.transport.Connector@86411 started
| 2009-01-31 16:39:12,114 ERROR [org.jboss.remoting.transport.socket.SocketServerInvoker] (AcceptorThread[[SSL: ServerSocket[addr=/0.0.0.0,port=0,localport=3843]]]) SSLServerSocket error
| javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled.
| at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
| at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
| at org.jboss.remoting.util.SecurityUtility.accept(SecurityUtility.java:931)
| at org.jboss.remoting.transport.socket.SocketServerInvoker$AcceptThread.run(SocketServerInvoker.java:1003)
|
|
|
So the log says (the line marked in bold), that the configuration doesn't contain the server socket factory configuration, even though the configuration does have it. I looked at the org.jboss.remoting.transport.Connector.init() code:
| private void init()
| throws Exception
| {
| Map invokerConfig = new HashMap();
|
| if (locatorURI == null)
| {
| // InvokerLocator attribute not set; check to see if serverConfiguration is set.
| if (serverConfiguration != null)
| {
| getInvokerConfigFromServerConfiguration(invokerConfig);
| }
| // Check to see if Configuration attribute is set.
| else if (xml != null)
| {
| getInvokerConfigFromXML(invokerConfig);
| }
|
| configuration.putAll(invokerConfig);
| }
| if (locatorURI == null)
| {
| throw new IllegalStateException("Connector not configured with LocatorURI.");
| }
|
| InvokerLocator locator = new InvokerLocator(locatorURI);
|
| if (invoker == null)
| {
| // create the server invoker
| invoker = InvokerRegistry.createServerInvoker(locator, configuration);
|
|
|
Based on debugging, i can see that the "configuration" is always empty (even though the "invokerConfig" has all the relevant configurations) when the InvokerLocator is being created. That's because, the getInvokerConfigFromServerConfiguration (nor the getInvokerConfigFromXML) is ever called because of the if (locatorURI == null) condition never being satisfied. Looking at this code, those two methods getInvokerConfigFromXML/getInvokerConfigFromServerConfiguration are currently setting the locatorURI as well as populating the configurations. I guess those might have to be refactored so that populating the configurations is done separately, irrespective of whether locatorURI is set or not. As such, i refactored the Connector code to move the locatorURI creation and configuration setting into two separate independent methods and patched it in the AS5.0 GA. I'll mail you the patch separately (too long to post it here).
That patch got me one step closer to getting my client running, but it wasn't enough because i saw this in the logs:
2009-01-31 17:12:38,616 DEBUG [org.jboss.remoting.ServerInvoker] (HDScanner) The 'serverSocketFactory' attribute was set with a value, but the MBeanServer reference is null.
| 2009-01-31 17:12:38,620 DEBUG [org.jboss.remoting.ServerInvoker] (HDScanner) Could not create server socket factory by classname (jboss.remoting:service=ServerSocketFactory,type=SecurityDomainAdvanced). Error message: jboss.remoting:service=ServerSocketFactory,type=SecurityDomainAdvanced
| 2009-01-31 17:12:38,620 DEBUG [org.jboss.remoting.ServerInvoker] (HDScanner) SocketServerInvoker[0.0.0.0:3843] did not find server socket factory configuration as mbean service or classname. Creating default server socket factory.
| 2009-01-31 17:12:38,666 DEBUG [org.jboss.remoting.ServerInvoker] (HDScanner) SocketServerInvoker[0.0.0.0:3843] created server socket factory com.sun.net.ssl.internal.ssl.SSLServerSocketFactoryImpl@1df43bf
|
|
Since the Connector is now a MC Bean, it doesn't have a reference to the MBeanServer and hence the log (marked in bold). I'm not sure whether there's a way to inject MBean server into a MC Bean. The ugly hack that i could think of was to use the MBeanServerLocator.locateJBoss() to set the MBean Server. Definitely ugly since its not going to work outside AS.
private MBeanServer server = org.jboss.mx.util.MBeanServerLocator.locateJBoss();
Maybe there's a better way to get hold of the MBean Server into the MC bean (even though both are unrelated)?
With this additional change patched in, i was finally able to make my EJB3 client happy :) The deployment went fine and the client was able to lookup the bean invoke the operations.
Do you suggest i create a JIRA for this?
P.S: This is not critical for EJB3 because the MBean variant of these configurations (in my first post) works without any issues. I was just curious in using the MC Bean version, so started looking at it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206052#4206052
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206052
17 years
[JBossMQ] - ConnectionFactory not bound
by igain
Hi,
I am using jboss-4.2.0.GA version in a clustered environment.
We have 2 nodes in cluster.
In our JMS client code (i.e. reside in application server itself) when we are try to post some message to queue we often receive "NaminException:ConnectionFactory not bound".
I know that Jboss MQ run in singleton mode means on one of the node in cluster.
It works perfactly if request goes to the node which is having ConnectionFactory bound in its JNDI tree's java: name space, but when request goes to other node it fails to lookup same JNDI name even though it is in cluster.
following is the code snippet that we are using, we are using JVM-IL based connection factory, since our client and MDB reside in same JVM
| Properties p = new Properties();
| p.put(Context.INITIAL_CONTEXT_FACTORY,
| "org.jnp.interfaces.NamingContextFactory");
| p.put(Context.URL_PKG_PREFIXES, "jboss.naming:org.jnp.interfaces");
| p.put(Context.PROVIDER_URL, "localhost:1100"); // HA-JNDI port.
| ctx = InitialContext(p);
| ctx.lookup("java:/ConnectionFactory");
|
Please suggest what is wrong here in code ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206046#4206046
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206046
17 years