[JBoss JIRA] (JBMESSAGING-1754) Implement the JBossMQ behavior on JBM, when stopDelivery() is invoked via JMX console
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1754?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1754:
--------------------------------------
Fix Version/s: 1.4.8.SP11
(was: 1.4.8.SP10)
> Implement the JBossMQ behavior on JBM, when stopDelivery() is invoked via JMX console
> -------------------------------------------------------------------------------------
>
> Key: JBMESSAGING-1754
> URL: https://issues.jboss.org/browse/JBMESSAGING-1754
> Project: JBoss Messaging
> Issue Type: Feature Request
> Components: Messaging Core
> Affects Versions: 1.4.0.SP3.CP08
> Environment: JBoss-EAP-4.3_CP6, JBM-1.4.0-SP3_CP8P1
> Reporter: Tyronne Wickramarathne
> Assignee: Yong Hao Gao
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> When stopDelivery() is invoked via JMX console for any given MDB, the in process messages are rolled back to their corresponding destination without completing the process. This is however *not* a bug, but the expected behavior in JBM, for this is how it has defined the behavior of stopDelivery().
> However on JBossMQ, the in process messages are completed at first, before stopDelivery() is processed. Which means, the call made via stopDelivery() will be kept on hold, until all in process messages are successfully completed. The customers migrating from JBossMQ are seeing this as a compatibility issue, when porting their applications to work on JBM. Hence, would it be possible to accommodate the behavior seen in JBossMQ on JBM please ?
> I have tested this on both JBoss-EAP-4.3_CP6 as well as on JBoss-EAP-4.2_CP7. Both have the same code base for EJB3,JCA but not the JMS provider. Therefore, I'm raising this feature request under JBM.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JBMESSAGING-1780) When i change the default db schemas of jbm tables the DLQ - if it contains message - run in deadlock by the next server restart, because it wants to use the default schema instead of the modified db schema
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1780?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1780:
--------------------------------------
Fix Version/s: 1.4.8.SP11
(was: 1.4.8.SP10)
> When i change the default db schemas of jbm tables the DLQ - if it contains message - run in deadlock by the next server restart, because it wants to use the default schema instead of the modified db schema
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBMESSAGING-1780
> URL: https://issues.jboss.org/browse/JBMESSAGING-1780
> Project: JBoss Messaging
> Issue Type: Bug
> Affects Versions: 1.4.0.SP3.CP09, 1.4.5.GA, 1.4.6.GA
> Environment: JBoss 5.1.GA+Seam 2.1.1.GA+mysql 5.1
> Reporter: bb bb
> Assignee: Yong Hao Gao
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> At first, I modified the default schema of jbm tables in mysql-persistence-service.xml
> so, I changed the sql properties JBM_DUAL to newSchema.JBM_DUAL and so on...
> Everything works fine with the modified schema, until I add a posion message to the dead letter queue.
> Then I want to restart the JBoss server, I get an exception to it run in dead lock, because didn't find the jbm_msg tables (but it would be newSchema.jbm_msg )
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JBMESSAGING-1777) Error in addMessageIDInHeader while bridging from JBossMQ
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1777?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1777:
--------------------------------------
Fix Version/s: 1.4.8.SP11
(was: 1.4.8.SP10)
> Error in addMessageIDInHeader while bridging from JBossMQ
> ---------------------------------------------------------
>
> Key: JBMESSAGING-1777
> URL: https://issues.jboss.org/browse/JBMESSAGING-1777
> Project: JBoss Messaging
> Issue Type: Bug
> Affects Versions: 1.4.3.GA
> Environment: JBoss AS 5.1.0.GA
> Reporter: Pedro Gontijo
> Assignee: Yong Hao Gao
> Labels: JMSXDeliveryCount, addMessageIDInHeader, bridge, jbossmq
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> When addMessageIDInHeader is set to true in a JBossMQ->JBM bridge scenerio the following error occurs:
> WARN [org.jboss.jms.server.bridge.Bridge] (Thread-27) jboss.messaging:name=MyBridge,service=Bridge Failed to send + acknowledge batch, closing JMS objects
> javax.jms.JMSException: Illegal property name: JMSXDeliveryCount
> at org.jboss.mq.SpyMessage.checkProperty(Unknown Source)
> at org.jboss.mq.SpyMessage.setObjectProperty(Unknown Source)
> at org.jboss.jms.server.bridge.Bridge.addMessageIDInHeader(Bridge.java:1481)
> at org.jboss.jms.server.bridge.Bridge.sendMessages(Bridge.java:1391)
> at org.jboss.jms.server.bridge.Bridge.sendBatchNonTransacted(Bridge.java:1261)
> at org.jboss.jms.server.bridge.Bridge.sendBatch(Bridge.java:1375)
> at org.jboss.jms.server.bridge.Bridge.access$1900(Bridge.java:68)
> at org.jboss.jms.server.bridge.Bridge$BatchTimeChecker.run(Bridge.java:1638)
> at java.lang.Thread.run(Thread.java:595)
> As you can see the error is due JMSX properties, actually, because the addMessageIDInHeader sets then in the MQ message (which is not allowed).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JBMESSAGING-1763) Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1763?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1763:
--------------------------------------
Fix Version/s: 1.4.8.SP11
(was: 1.4.8.SP10)
> Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBMESSAGING-1763
> URL: https://issues.jboss.org/browse/JBMESSAGING-1763
> Project: JBoss Messaging
> Issue Type: Bug
> Components: JMS Remoting
> Affects Versions: 1.4.5.GA, 1.4.6.GA
> Environment: OS: Windows Server 2003. JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA, JBoss Remoting 2.2.3 SP1
> Reporter: mingjun jiang
> Assignee: Yong Hao Gao
> Labels: Failure, are, be, by, cable, caused, closed, connection, ethernet, if, manually, out, pulling, they, won't
> Fix For: 1.4.8.SP11
>
> Attachments: jboss-test-log for JBM1.4.5 & Remoting 2.2.3 SP1.zip, QReceiver.java, QSender.java, remoting-bisocket-service.xml
>
>
> We are using JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA and JBoss Remoting 2.2.3 SP1. In our application, there are a lot of Message listeners running on the client side, these message listeners will receive messages from queue/topic deployed in JBoss Messaging
> Configuration:
> We created our own JMS Connection factory which uses the default remoting connector. As you know, the default remoting connector is configured to use the bisocket transport. We didn't change the default value of the remoting connector
> During we run our application, we open the JBoss web console to monitor the value of currentClientPoolSize under "Jboss.remoting" JMX MBean.
>
> How to reproduce this issue:
> 1. Run 5 message listeners in the client side to receive messages from JBoss Messaging, then we observe the value of currentClientPoolSize is 10
> 2. After processing several messages, we manually pull out the ethernet cable. The value of currentClientPoolSize is still 10.
> 3. We run another 5 message listeners in client side, then the value of currentClientPoolSize will become 20
> 4. After we do the same operations above several times, the value of currentClientPoolSize will increase continuously. Once the value of currentClientPoolSize is equal to the MaxPoolSize, then the subsequent incoming client requests will hang, and we will encounter the following exception in server side
> 2009-10-20 18:08:09,655 ERROR [org.jboss.remoting.transport.socket.ServerThread] Worker thread initialization failure
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:168)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
> at java.io.FilterInputStream.read(FilterInputStream.java:66)
> at org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:859)
> at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:545)
> at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:406)
> at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173)
> Conclusion: JBoss Messaging won't close the failure connections if they are caused by manually pulling out ethernet cable. As a result, the value of currentClientPoolSize will increase continuously and finally the new client requests will hang
> Note: If we killed the process of message listener in client side, then the value of currentClientPoolSize will decrease to 0 immediately, it seems that the server could detect the failure connection and perform the corresponding resource releasing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JBMESSAGING-1790) A single lagging JBM topic subscriber can cause all publishes to lag
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1790?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1790:
--------------------------------------
Fix Version/s: 1.4.8.SP11
(was: 1.4.8.SP10)
> A single lagging JBM topic subscriber can cause all publishes to lag
> --------------------------------------------------------------------
>
> Key: JBMESSAGING-1790
> URL: https://issues.jboss.org/browse/JBMESSAGING-1790
> Project: JBoss Messaging
> Issue Type: Bug
> Components: Messaging Core
> Affects Versions: 1.4.3.GA
> Environment: JBoss 5.1.0_GA, JDK 1.6.0_14 and JDK 1.6.0_18, multiple versions of Windows (2008, 2003, Vista)
> Reporter: Jason Burton
> Assignee: Yong Hao Gao
> Fix For: 1.4.8.SP11
>
> Attachments: stack_traces.zip
>
>
> We have an application that makes heavy use of JMS topics. The attached stack traces lead me to believe that we have one client that has some sort of network problem and that JBM is trying to write messages to it. Evidently this client's socket isn't working anymore. That's no problem (and maybe could be expected), but this causes every other client publish to hang.
> The attached stack traces are from JBoss and taken 10 seconds apart during an occurence of this. During this time, we observed that one or more calls to JBossMessageProducer.publish() took 50 seconds to complete (normally takes 2-5 milliseconds). Best I can tell, the "WorkManager(2)-3" thread is the culprit. Over the 50 seconds, it seemed to be stuck in a socketWrite() and has object <0x143a2250> locked. There are a few other publishing threads waiting on that lock.
> I'm pretty sure this relates to a closed bug:
> https://jira.jboss.org/jira/browse/JBMESSAGING-1220
> This bug report states to run a client out of memory to reproduce the problem, but at the point of the attached server stack traces. there aren't any clients that are out of memory. We have been able to reproduce this by running a client out of memory, though. That bug report stated to reduce the prefetchSize to a number of messages whose size would be under the TCP window size. Best I can tell by searching, the TCP window size defaults to 16K on Windows. It is definitely possible that the messages we send are larger than 16K, so even setting the prefetchSize to 1 would be larger that the TCP window size.
> Let me know if you need any more information.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JBMESSAGING-1789) setFetchSize used in JDBCPersistenceManager with too large value for oracle (200000)
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1789?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1789:
--------------------------------------
Fix Version/s: 1.4.8.SP11
(was: 1.4.8.SP10)
> setFetchSize used in JDBCPersistenceManager with too large value for oracle (200000)
> ------------------------------------------------------------------------------------
>
> Key: JBMESSAGING-1789
> URL: https://issues.jboss.org/browse/JBMESSAGING-1789
> Project: JBoss Messaging
> Issue Type: Bug
> Components: Messaging Core Persistence
> Affects Versions: 1.4.5.GA, 1.4.6.GA, 1.4.8.GA
> Environment: oracle
> Reporter: Simo Nikula
> Assignee: Yong Hao Gao
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> in method loadFromStart (line 984 in 1.4.6) fetchSize is set based on parameter number which is as default 200000.
> setting max rows using setMaxRows with same value would be correct way to limit result set.
> java.sql.SQLException: Bigger type length than Maximum
> at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:70)
> at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:133)
> at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:199)
> at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:263)
> at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:271)
> at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:445)
> at oracle.jdbc.driver.T4CMAREngine.buffer2Value(T4CMAREngine.java:2253)
> at oracle.jdbc.driver.T4CMAREngine.unmarshalUB2(T4CMAREngine.java:1101)
> at oracle.jdbc.driver.T4C8TTIrxh.unmarshalV10(T4C8TTIrxh.java:115)
> at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:654)
> at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:194)
> at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:791)
> at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:866)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1186)
> at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3387)
> at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3431)
> at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1491)
> at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:342)
> at org.jboss.messaging.core.impl.JDBCPersistenceManager.loadFromStart(JDBCPersistenceManager.java:988)
> at org.jboss.messaging.core.impl.PagingChannelSupport.load(PagingChannelSupport.java:211)
> at org.jboss.jms.server.destination.TopicService.startService(TopicService.java:92)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
> at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JBMESSAGING-1781) JMS failover recovery handling failed on cluster setup when the server running with JBOss + MySQL crashes.
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1781?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1781:
--------------------------------------
Fix Version/s: 1.4.8.SP11
(was: 1.4.8.SP10)
> JMS failover recovery handling failed on cluster setup when the server running with JBOss + MySQL crashes.
> ----------------------------------------------------------------------------------------------------------
>
> Key: JBMESSAGING-1781
> URL: https://issues.jboss.org/browse/JBMESSAGING-1781
> Project: JBoss Messaging
> Issue Type: Bug
> Components: JMS Clustering
> Affects Versions: 1.4.3.GA
> Environment: java version "1.6.0_17"
> JBoss version 5.1.0.GA
> Operating System: Solaris & Linux
> Reporter: Null Reference
> Fix For: 1.4.8.SP11
>
>
> JBoss Messaging failover recovery handling failed on cluster setup when the server running with JBOss + MySQL crashes.
> Setup details
> server1: JBoss App server + MySQL
> server2: JBoss App server
> server1 was crashed for some hardware failure, server2 detects that the server1 leaves the cluster and starts the failover recovery operation, failover
> recovery involves clean up operation from its local map and database, how ever MySQL is down at this moment so the clean up operation failed with some re-tries.
> Restarting the crashed server does not help to join the existing cluster group, the reason being failover recovery has failed.
> 009-11-24 21:43:24,101 ERROR [main]-[org.jboss.messaging.util.ExceptionUtil] org.jboss.messaging.core.jmx.MessagingPostOfficeService@1a67848 startService
> java.lang.IllegalArgumentException: Cannot start post office since there is already a post office in the cluster with the same node id (215). Are you sure
> you have given each node a unique node id during installation?
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.start(MessagingPostOffice.java:372)
> at org.jboss.messaging.core.jmx.MessagingPostOfficeService.startService(MessagingPostOfficeService.java:462)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
> at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
> at $Proxy38.start(Unknown Source)
> at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
> at org.jboss.system.ServiceController.start(ServiceController.java:460)
> at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
> at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
> at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
> at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
> at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
> at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> at org.jboss.Main.boot(Main.java:221)
> at org.jboss.Main$1.run(Main.java:556)
> at java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (JBMESSAGING-1794) SecurityStore not applied correctly
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1794?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1794:
--------------------------------------
Fix Version/s: 1.4.8.SP11
(was: 1.4.8.SP10)
> SecurityStore not applied correctly
> -----------------------------------
>
> Key: JBMESSAGING-1794
> URL: https://issues.jboss.org/browse/JBMESSAGING-1794
> Project: JBoss Messaging
> Issue Type: Feature Request
> Components: JMS Security
> Affects Versions: 1.4.6.GA
> Reporter: Justin Bertram
> Assignee: Yong Hao Gao
> Fix For: 1.4.8.SP11
>
>
> The "SecurityStore" in messaging-jboss-beans.xml doesn't appear to be getting applied correctly. Steps to reproduce:
> 1) Unzip a fresh copy of JBoss EAP 5
> 2) Change the "suckerPassword" attribute in <JBOSS_HOME>/server/all/deploy/messaging/messaging-jboss-beans.xml
> 3) Activate TRACE logging with this category in <JBOSS_HOME>/server/all/conf/jboss-log4j.xml:
> <category name="org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore">
> <priority value="TRACE"/>
> </category>
> 4) Start the server: <JBOSS_HOME>/bin/run.sh -c all
> 5) This comes up in the log:
> TRACE [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (main) authenticating user JBM.SUCKER
> TRACE [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (main) Authenticating sucker user
> WARN [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (main) WARNING! POTENTIAL SECURITY RISK. It has been detected that the MessageSucker component which sucks messages from one node to another has not had its password changed from the installation default. Please see the JBoss Messaging user guide for instructions on how to do this.
> ERROR [org.jboss.messaging.util.ExceptionUtil] (main) ConnectionFactoryEndpoint[jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory] createFailoverConnectionDelegate [da-yi5epx6g-1-0jhcpx6g-twc79y-100j3]
> javax.jms.JMSSecurityException: User JBM.SUCKER is NOT authenticated
> at org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore.authenticate(JBossASSecurityMetadataStore.java:223)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
> at javax.management.StandardMBean.invoke(StandardMBean.java:391)
> at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy99.authenticate(Unknown Source)
> at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegateInternal(ServerConnectionFactoryEndpoint.java:233)
> at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegate(ServerConnectionFactoryEndpoint.java:171)
> at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.org$jboss$jms$server$endpoint$advised$ConnectionFactoryAdvised$createConnectionDelegate$aop(ConnectionFactoryAdvised.java:108)
> at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.createConnectionDelegate(ConnectionFactoryAdvised.java)
> at org.jboss.jms.wireformat.ConnectionFactoryCreateConnectionDelegateRequest.serverInvoke(ConnectionFactoryCreateConnectionDelegateRequest.java:91)
> at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:157)
> at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:897)
> at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> at org.jboss.remoting.Client.invoke(Client.java:1917)
> at org.jboss.remoting.Client.invoke(Client.java:768)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:178)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
> at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:80)
> at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateConnectionDelegate_15295742.invoke(StateCreationAspect_z_handleCreateConnectionDelegate_15295742.java)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
> at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
> at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager$ConnectionInfo.start(ClusterConnectionManager.java:669)
> at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager.ensureAllConnectionsCreated(ClusterConnectionManager.java:419)
> at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager.notify(ClusterConnectionManager.java:241)
> at org.jboss.messaging.core.impl.DefaultClusterNotifier.sendNotification(DefaultClusterNotifier.java:72)
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.putReplicantLocally(MessagingPostOffice.java:1245)
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.put(MessagingPostOffice.java:1525)
> at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:252)
> at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:206)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
> at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
> at $Proxy38.start(Unknown Source)
> at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
> at org.jboss.system.ServiceController.start(ServiceController.java:460)
> at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
> at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
> at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:403)
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:308)
> at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:256)
> at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> at org.jboss.Main.boot(Main.java:221)
> at org.jboss.Main$1.run(Main.java:556)
> at java.lang.Thread.run(Thread.java:619)
> It appears that org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint is creating the connection with the password from messaging-jboss-beans.xml, but org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore is authenticating it with the information from messaging-service.xml (which uses the default password since "SuckerPassword" is commented out).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month