[JBoss JIRA] (JBMESSAGING-1731) Expose the JBoss Messaging Cluster partition in JMX
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1731?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1731:
--------------------------------------
Fix Version/s: 1.4.8.SP12
(was: 1.4.8.SP11)
> Expose the JBoss Messaging Cluster partition in JMX
> ---------------------------------------------------
>
> Key: JBMESSAGING-1731
> URL: https://issues.jboss.org/browse/JBMESSAGING-1731
> Project: JBoss Messaging
> Issue Type: Feature Request
> Components: Messaging Core
> Affects Versions: 1.4.4.GA
> Reporter: Brad Maxwell
> Assignee: Yong Hao Gao
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12
>
>
> Background:
> I have had a request wanting access to the members of the JBoss Messaging Cluster so that they can configure the Recovery plugin without having to hard code hosts in the configuration file. With the JBoss Messaging Cluster Partition in JMX they would be able to get an accurate list of the members in the Messaging cluster.
--
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
11 years, 8 months
[JBoss JIRA] (JBMESSAGING-1759) JGroups cannot process incoming messages during the method execution
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1759?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1759:
--------------------------------------
Fix Version/s: 1.4.8.SP12
(was: 1.4.8.SP11)
> JGroups cannot process incoming messages during the method execution
> --------------------------------------------------------------------
>
> Key: JBMESSAGING-1759
> URL: https://issues.jboss.org/browse/JBMESSAGING-1759
> Project: JBoss Messaging
> Issue Type: Bug
> Components: JMS Clustering
> Affects Versions: 1.4.0.SP3.CP07
> Environment: JBossMessaging-1.4.0_SP3_CP7
> Reporter: Tyronne Wickramarathne
> Assignee: Yong Hao Gao
> Priority: Critical
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12
>
>
> The GroupMember#viewAccepted() takes 31min on the IncomingPacketHandler thread. The JGroups cannot process incoming messages during this method execution. It's completely blocked and leads the following log and subsequent WARNs.
> 2009-11-11 11:50:12.634 [ViewHandler] WARN [GMS] - failed to collect all ACKs (1) for view [192.168.1.221:49898|2] [192.168.1.221:49898] after 2000ms, missing ACKs from [192.168.1.221:49898] (received=[]), local_addr=192.168.1.221:49898
--
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
11 years, 8 months
[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.SP12
(was: 1.4.8.SP11)
> 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.SP12
>
>
> 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
11 years, 8 months
[JBoss JIRA] (JBMESSAGING-1750) Allow arbitrary SQL statements for JDBCPersistenceManagerService
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1750?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1750:
--------------------------------------
Fix Version/s: 1.4.8.SP12
(was: 1.4.8.SP11)
> Allow arbitrary SQL statements for JDBCPersistenceManagerService
> ----------------------------------------------------------------
>
> Key: JBMESSAGING-1750
> URL: https://issues.jboss.org/browse/JBMESSAGING-1750
> Project: JBoss Messaging
> Issue Type: Feature Request
> Components: Configuration and Management
> Affects Versions: 1.4.0.SP3.CP08
> Reporter: Justin Bertram
> Assignee: Yong Hao Gao
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12
>
>
> Allow arbitrary SQL statements in the SQLProperties field of org.jboss.messaging.core.jmx.JDBCPersistenceManagerService which will be executed just like all the others (e.g. if CreateTablesOnStartup = "true"). I imagine the statements will need to be named according to some pattern (e.g. "CREATE_*").
> This functionality will allow greater flexibility for our RDBMS support (e.g. a user could configure support for Oracle TimesTen).
--
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
11 years, 8 months
[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.SP12
(was: 1.4.8.SP11)
> 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.SP12
>
>
> 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
11 years, 8 months
[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.SP12
(was: 1.4.8.SP11)
> 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.SP12
>
>
> 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
11 years, 8 months
[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.SP12
(was: 1.4.8.SP11)
> 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.SP12
>
>
> 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
11 years, 8 months