We are using the jboss application server version 4.2.3.
After starting the server, One of the destination queue 'testQueue' bound becomes to CLOSED state.
While checking the logs, the below information was present.
2014-01-07 20:55:49,855 INFO [genericEventJmsContainer-1]- Setup of
JMS message listener invoker failed for destination
'JBossQueue[testQueue]' - trying to recover. Cause: The object is
closed javax.jms.IllegalStateException: The object is closed at
org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:159)
at
org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at
org.jboss.jms.client.delegate.ClientConsumerDelegate$receive_N8299950230150603585.invokeNext(ClientConsumerDelegate$receive_N8299950230150603585.java) at
org.jboss.jms.client.delegate.ClientConsumerDelegate.receive(ClientConsumerDelegate.java)
at
org.jboss.jms.client.JBossMessageConsumer.receive(JBossMessageConsumer.java:86)
at
org.springframework.jms.connection.CachedMessageConsumer.receive(CachedMessageConsumer.java:74)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveMessage(AbstractPollingMessageListenerContainer.java:405)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:308)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:261)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:982)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:974)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:876)
at java.lang.Thread.run(Thread.java:662)
Could anyone kindly provide us with some inputs on the reason why a selected destination becomes to CLOSED state after a certain period of time from the server start time?
It may be the bug https://issues.jboss.org/browse/JBESB-1491 which is in version 4.2.1 ,which is fixed version is 4.3.
Please share the JMS configuration you have done for Queue.
Also you can find related topic http://docs.jboss.org/jbossas/jboss4guide/r1/html/ch6.chapt.html
Thanks for your comments
<mbean code="org.jboss.jms.server.destination.QueueService" name="jboss.esb.quickstart.destination:service=Queue,name=testQueue" xmbean-dd="xmdesc/Queue-xmbean.xml"> <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer </depends> <depends>jboss.messaging:service=PostOffice</depends> <attribute name="RedeliveryDelay">1000</attribute> <attribute name="MaxDeliveryAttempts">15</attribute> <attribute name="Clustered">true</attribute> </mbean>
Above is a sample configuration we make for a Queue destination.
These queues are defined in JBOSS SOA server version 4.3 and being listened by components deployed in JBOSS Application Server version 4.2.3
Related
We are creating a Mule application which will be running in a container on Kubernetes and will be in a replica set that will be connecting to JMS 2.0 Red Hat AMQ 7 (based on ActiveMQ Artemis).
The pom.xml has been configured to get the jms client:
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>artemis-jms-client-all</artifactId>
<version>2.10.1</version>
</dependency>
And the JMS config is configured as:
<jms:config name="JMS_Config" doc:name="JMS Config" doc:id="8621b07d-b203-463e-bbbe-76eb03741a61" >
<jms:generic-connection specification="JMS_2_0" username="${mq.user}" password="${mq.password}" clientId="${mq.client.id}">
<reconnection >
<reconnect-forever frequency="${mq.reconnection.frequency}" />
</reconnection>
<jms:connection-factory >
<jms:jndi-connection-factory connectionFactoryJndiName="ConnectionFactory" >
<jms:name-resolver-builder jndiInitialContextFactory="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory" jndiProviderUrl="${mq.brokerurl}"/>
</jms:jndi-connection-factory>
</jms:connection-factory>
</jms:generic-connection>
<jms:consumer-config>
<jms:consumer-type >
<jms:topic-consumer shared="true" durable="true"/>
</jms:consumer-type>
</jms:consumer-config>
<jms:producer-config persistentDelivery="true"/>
</jms:config>
Then in the JMS listener component:
<jms:listener doc:name="EMS JMS Listener" doc:id="318b4f08-daf6-41f4-944b-3ec1420d5c12" config-ref="JMS_Config" destination="${mq.incoming.queue}" ackMode="AUTO" >
<jms:consumer-type >
<jms:topic-consumer shared="true" subscriptionName="${mq.sub.name}" durable="true"/>
</jms:consumer-type>
<jms:response sendCorrelationId="ALWAYS" />
</jms:listener>
The variables are set as:
mq.client.id=client-id-135a9514-d4d5-4f52-b01c-f6ca34a76b40
mq.sub.name=my-sub
mq.incoming.queue=my-queue
Is this the best way to configure the client? As we have seen errors in the logs when deployed to K8s regarding connections to the AMQ server:
javax.jms.InvalidClientIDException: client-id-135a9514-d4d5-4f52-b01c-f6ca34a76b40 was already set into another connection
In JMS 2.0 you don't have to set the client identifier when creating a shared durable subscription. However, if you do set the client identifier then it must be unique per connection. For whatever reason (e.g. due to Mule or perhaps K8s) multiple connections are being created and since each connection is using the same client identifier you're receiving the javax.jms.InvalidClientIDException.
Remove clientId="${mq.client.id}" from your configuration and the javax.jms.InvalidClientIDException should go away.
I'm using jboss 5.0.1 with multiple data sources configured.
It seems that on startup, if one of those is configured incorrectly, jboss throws an exception and refuses to start.
I would like to know if it's possible to configure jboss to be resilient to these kind of problems.
You can configure the connections in the xml file which holds the connection parameters/mapping. In my case, i am using a microsoft sql server as the datasource, so i have to use the mssql-ds.xml file (inside the server/deploy directory) to specify:
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
<jndi-name>myTestServer</jndi-name>
<connection-url>jdbc:sqlserver://xxx.xxx.xxx.xxx:1433;databaseName=MyDB</connection-url>
<driver-class>com.microsoft.sqlserver.jdbc.SQLServerDriver</driver-class>
<user-name>test</user-name>
<password>abc123</password>
<min-pool-size>10</min-pool-size>
<max-pool-size>25</max-pool-size>
<!-- sql to call when connection is created -->
<new-connection-sql>select getdate()</new-connection-sql>
<!-- -->
<!-- sql to call on an existing pooled connection when it is obtained from pool
This will be run before a managed connection is removed from the pool
for use by a client -->
<check-valid-connection-sql>select getdate()</check-valid-connection-sql>
</local-tx-datasource>
</datasources>
This helps control the connections in the pool, and should stop dodgy deadlocks. I'm not entirely sure whether this will test the current transaction level on the connection in question, so if you want to make absolutely sure, you can try: <check-valid-connection-sql>IF ##TRANCOUNT > 0 raiserror ('%s',18,1,'Open Transactions Discovered')</check-valid-connection-sql> This will give you an explicit SQLException to handle.
But if you are getting an error on startup, it would be very useful to see what those errors are.
I am using jboss-5.1 to deploy message driven bean which is used to subscribe messages from a third party queue.
Around 16 messages were posted to that queue but they remained pending in our subscriber queue. I restarted the server and the messages were readily picked.
As much as I have analysed, I think maxsize and maxsession could have affected it, as both are 15. But I do not understand if there was some real issue, how it got solved by just restarting.
The logs were in error mode. I did not get the full stack trace.
This is the snippet of that error log.
[2012-10-30 17:01:00,228] [MQQueueAgent (GQH1_PLANNING_MDM_001)]
[ERROR] STDERR: 2012.10.30 17:01:00 MQJMS1023E rollback failed
[2012-10-30 17:01:00,228] [exceptionDelivery0] [WARN ]
org.jboss.resource.adapter.jms.inflow.JmsActivation: Failure in jms activation
org.jboss.resource.adapter.jms.inflow.JmsActivationSpec#85d0d(ra=org.jboss.resource.adapter.jms.JmsResourceAdapter#b21aae
destination=remotewsmq/NOTIFICATION_PLANNING_MDM_001.SUBQ
destinationType=javax.jms.Queue tx=true durable=false reconnect=10 provider=RemoteWSMQJMSProvider
user=null maxMessages=1 minSession=1 maxSession=5 keepAlive=60000 useDLQ=false)
GQH1_PLANNING_MDM_001: The name of the queue used for subscribing.
The files that I use to configure the properties of the MDBs are as follows.
1.ejb3-interceptors-aop.xml
<domain name="Message Driven Bean" extends="Intercepted Bean" inheritBindings="true">
<bind pointcut="execution(public * *->*(..))">
<interceptor-ref name="org.jboss.ejb3.security.AuthenticationInterceptorFactory"/>
<interceptor-ref name="org.jboss.ejb3.security.RunAsSecurityInterceptorFactory"/>
</bind>
<!-- TODO: Authorization? -->
<bind pointcut="execution(public * *->*(..))">
<interceptor-ref name="org.jboss.ejb3.tx.CMTTxInterceptorFactory"/>
<interceptor-ref name="org.jboss.ejb3.stateless.StatelessInstanceInterceptor"/>
<interceptor-ref name="org.jboss.ejb3.tx.BMTTxInterceptorFactory"/>
<interceptor-ref name="org.jboss.ejb3.AllowedOperationsInterceptor"/>
<interceptor-ref name="org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor"/>
<!-- interceptor-ref name="org.jboss.ejb3.interceptor.EJB3InterceptorsFactory"/ -->
<stack-ref name="EJBInterceptors"/>
</bind>
<annotation expr="class(*) AND !class(#org.jboss.ejb3.annotation.Pool)">
#org.jboss.ejb3.annotation.Pool (value="StrictMaxPool", maxSize=15, timeout=10000)
</annotation>
</domain>
2.standardjboss.xml
<invoker-proxy-binding>
<name>message-driven-bean</name>
<invoker-mbean>default</invoker-mbean>
<proxy-factory>org.jboss.ejb.plugins.jms.JMSContainerInvoker</proxy-factory>
<proxy-factory-config>
<JMSProviderAdapterJNDI>DefaultJMSProvider</JMSProviderAdapterJNDI>
<ServerSessionPoolFactoryJNDI>StdJMSPool</ServerSessionPoolFactoryJNDI>
<CreateJBossMQDestination>false</CreateJBossMQDestination>
<!-- WARN: Don't set this to zero until a bug in the pooled executor is fixed -->
<MinimumSize>1</MinimumSize>
<MaximumSize>15</MaximumSize>
<KeepAliveMillis>30000</KeepAliveMillis>
<MaxMessages>1</MaxMessages>
<MDBConfig>
<ReconnectIntervalSec>10</ReconnectIntervalSec>
<DLQConfig>
<DestinationQueue>queue/DLQ</DestinationQueue>
<MaxTimesRedelivered>10</MaxTimesRedelivered>
<TimeToLive>0</TimeToLive>
</DLQConfig>
</MDBConfig>
</proxy-factory-config>
</invoker-proxy-binding>
<activation-config-property>
<activation-config-property-name>maxSession</activation-config-property-name>
<activation-config-property-value>15</activation-config-property-value>
</activation-config-property>
3.jms-ds.xml
<?xml version="1.0" encoding="UTF-8"?>
<connection-factories>
<!-- ==================================================================== -->
<!-- JMS Stuff -->
<!-- ==================================================================== -->
<!--
The JMS provider loader. Currently pointing to a non-clustered ConnectionFactory. Need to
be replaced with a clustered non-load-balanced ConnectionFactory when it becomes available.
See http://jira.jboss.org/jira/browse/JBMESSAGING-843.
-->
<mbean code="org.jboss.jms.jndi.JMSProviderLoader"
name="jboss.messaging:service=JMSProviderLoader,name=JMSProvider">
<attribute name="ProviderName">DefaultJMSProvider</attribute>
<attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
<attribute name="FactoryRef">java:/XAConnectionFactory</attribute>
<attribute name="QueueFactoryRef">java:/XAConnectionFactory</attribute>
<attribute name="TopicFactoryRef">java:/XAConnectionFactory</attribute>
</mbean>
<!-- JMS XA Resource adapter, use this to get transacted JMS in beans -->
<tx-connection-factory>
<jndi-name>JmsXA</jndi-name>
<xa-transaction/>
<rar-name>jms-ra.rar</rar-name>
<connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
<config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
<config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property>
<max-pool-size>20</max-pool-size>
<security-domain-and-application>JmsXARealm</security-domain-and-application>
<depends>jboss.messaging:service=ServerPeer</depends>
</tx-connection-factory>
</connection-factories>
Please help.
If the listener did not try to reconnect, then it might be the messages pending which caused it to fail.
According to the error, a transaction ROLLBACK call failed. After the failure, the queue manager probably held those messages in an outstanding unit of work. Restarting the server would have closed the connection at which point the queue manager will have rolled back the transaction on behalf of the application. On restart, the application will create a new UOW and retrieve the messages.
Look in WebSphere MQ's queue manager error logs and global error logs to determine whether the error was caused by a resource shortage. It may be necessary to increase the size of the queue manager transaction logs or to tune transaction parameters such as MAXUOW.
You may also need to update the MQ client version or Queue Manager version. According to this Technote, WebSphere MQ JMS classes were updated as of 6.0.2.3 to fix a bug that resulted in MQJMS1023E errors. If you need to update the client version, it is available as a free download as SupportPac MQC75. A new client is able to run with any back level queue manager. After upgrading, the app benefits from the bug fixes and performance enhancements of the new client code and provides API functionality appropriate for the version of Queue Manager to which it connects. What version of WebSphere MQ JMS client is currently installed? What version of WebSphere MQ queue manager is currently installed?
For JAAS authentication I have configured a datasource as follows:
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
<jndi-name>jdbc/SomeDS</jndi-name>
<connection-url>jdbc:path-to-server</connection-url>
<driver-class>interbase.interclient.Driver</driver-class>
<user-name>DBUSER</user-name>
<password>dbpass</password>
<min-pool-size>0</min-pool-size>
<metadata>
<type-mapping>Firebird</type-mapping>
</metadata>
</local-tx-datasource>
</datasources>
Unfortunately JBoss keeps the database connection open which can cause severe performance problems on our InterBase database.
As this connection is used only by the JAAS module internally, our web application has no way to force-close the connection.
Is there a way to tell JBoss to close connections after use?
Have you tried adding <idle-timeout-minutes>? - It defines the maximum time a connection may be idle before being closed. Setting to 0 disables it. Default is 15 minutes.
See http://community.jboss.org/wiki/ConfigDataSources for details.
I'm trying to migrate from jboss 4 to jboss 6 with an application i have running on jboss 4.
But when i try to run the application i get the following exception:
DEPLOYMENTS IN ERROR:
Deployment "jboss.j2ee:binding=message-driven-bean,jndiName=local/ProjectMessage#15042526,plugin=invoker,service=EJB" is in error due to the following reason(s): org.jboss.deployment.DeploymentException: The message-destination 'PhysicalQueue' has no jndi-name in jboss.xml
This is a part of the jboss.xml file:
<message-driven>
<ejb-name>ProjectMessage</ejb-name>
<destination-jndi-name>queue/PhysicalQueue</destination-jndi-name>
</message-driven>
I have created the queue in the jmx-console.
I have tried to search for a solution for this problem, but i can't seem to find any.
Does anybody have a clue/suggestion of what could be wrong?
Thanks in advance!
The MDB error occurs because the queue does not exist when the MDB deploys. Once you create the queue in JMXConsole, it's too late (unless you're really fast...:) ) and the queue configuration is not retained after AS restart.
You need to define your queue in deploy/hornetq/hornetq-jms.xml.
Something like this:
<queue name="PhysicalQueue">
<entry name="/queue/PhysicalQueue"/>
</queue>