[JBoss JIRA] Created: (JBAS-4032) Restore jboss.partition.name property replacement in clustering beans.xml files
by Brian Stansberry (JIRA)
Restore jboss.partition.name property replacement in clustering beans.xml files
-------------------------------------------------------------------------------
Key: JBAS-4032
URL: http://jira.jboss.com/jira/browse/JBAS-4032
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Priority: Minor
Fix For: JBossAS-5.0.0.Beta2
Pending completion of JBMICRONTAINER-143, I removed syntax from like the following from the clustering -beans.xml files:
<annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=HASingletonDeploymentScanner,partitionName=${jboss.partition.name:DefaultPartition}", exposedInterface=org.jboss.ha.singleton.HASingletonDeploymentScannerMBean.class, registerDirectly=
true)</annotation>
This task is a reminder to restore it once the microcontainer issue is resolved.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months
[JBoss JIRA] Created: (EJBTHREE-779) MDB doesn't rebind after JBOSS MQ recover
by Ramil Israfilov (JIRA)
MDB doesn't rebind after JBOSS MQ recover
------------------------------------------
Key: EJBTHREE-779
URL: http://jira.jboss.com/jira/browse/EJBTHREE-779
Project: EJB 3.0
Issue Type: Bug
Components: Clustering
Affects Versions: EJB 3.0 RC9 - FD
Environment: Solarisx86, JDK1.5_06
Reporter: Ramil Israfilov
Priority: Critical
Fix For: EJB 3.0 RC10 - FD
I have an MDB which is described using annotations:
@Depends("jboss.mq:service=JMSProviderLoader,name=HAJNDIJMSProvider")
@MessageDriven(name = "EJBExecutorMDB", activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/certione/ExecutorQueue"),
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "AUTO_ACKNOWLEDGE"),
@ActivationConfigProperty(propertyName = "maxSession", propertyValue = "4"),
@ActivationConfigProperty(propertyName = "dLQMaxResent", propertyValue = "4"),
@ActivationConfigProperty(propertyName = "SubscriptionDurability", propertyValue = "Durable") },
messageListenerInterface=MessageListener.class)
public class EJBExecutorMDB implements MessageListener {
...
}
I deploy it in clustered environment with HAJNDI and clustered JBOSS MQ.
So far so good.
Then cluster node on which JBOSS MQ is running crashed MDB is not rebind.
>From log file I see that JBOSS MQ successfully restarted on second node. And all permamnet queue destinations (defined in config files) are available,
but destinations which are defined in annotations don't exist.
And in log file I see that server constantly tries bind MDB, but got alway the same error:
javax.naming.NameNotFoundException: queue/certione/ExecutorQueue
at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:242)
at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:155)
at sun.reflect.GeneratedMethodAccessor140.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:258)
at $Proxy249.lookup(Unknown Source)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at org.jboss.util.naming.Util.lookup(Util.java:215)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.setupDestination(JmsActivation.java:399)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.setup(JmsActivation.java:306)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.handleFailure(JmsActivation.java:250)
at org.jboss.resource.adapter.jms.inflow.dlq.AbstractDLQHandler.onException(AbstractDLQHandler.java:94)
at org.jboss.mq.Connection$ExceptionListenerRunnable.run(Connection.java:1348)
at java.lang.Thread.run(Thread.java:595)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months
[JBoss JIRA] Created: (JBMESSAGING-850) Start connection factories from LocalTestServer.startServerPeer() as they used to be
by Ovidiu Feodorov (JIRA)
Start connection factories from LocalTestServer.startServerPeer() as they used to be
------------------------------------------------------------------------------------
Key: JBMESSAGING-850
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-850
Project: JBoss Messaging
Issue Type: Task
Components: Tests and Performance
Reporter: Ovidiu Feodorov
Assigned To: Clebert Suconic
Priority: Minor
Fix For: 1.2.1
Ovidiu wrote:
Your latest changes broke this convention, you deploy/start ConnectionFactories outside startServerPeer().
Specifically, you deploy stuff specified in "server/default/deploy/connection-factories-service.xml" in
ServiceContainer.startDatasource() (I renamed it temporarily startConnectionFactories()).
Clebert wrote:
I considered ConnectionFactory as part of the services started, and as ServerPeer would be also a
Service I thought about making the refactoring.
Ovidiu wrote:
ConnectionFactory are services, that is true, but it doesn't make any sense to deploy and start a
connection factory unless you have a messaging server running. ServerPeer is also a service,
and all of them are happily deployed together in startServerPeer(). Or at least they used to.
Clebert wrote:
Besides, the parameter to start the HTTPConnectionFactory is set on ServiceContainer
(boolean httpConnectionFactory), as this is cross-referenced with the start of Remoting.
Ovidiu wrote:
Fine. Use a variable and pass that variable to startServerPeer().
Clebert wrote:
If you like I could refactor the method back to LocalServer.
Ovidiu wrote:
Yes, please
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
18 years, 10 months