Is it possible to manage connection timeouts or errors in a MessageDrivenBean?
You can make the factory to retry connecting a certain number of times but... is it possible to make some actions each time that a reconnection retrial is neccesary? Is it possible to register an ExceptionListener into the MessageDrivenBean's connection somehow?
Thanks a lot.
Finally I wasn't able to do this but I changed jmsjra to JMSJCA that fits better my needings. JMSJCA is included in Glassfish ESB project.
You can always have some sort of error topic or queue that you can post the exception to from your MDB. Including the correlationID in the error message to synchronize with the original message if that is desired.
Related
Hi I am using a jmslistener annotation to recieve messages from tibco queue. I am DefaultJmsListenerContainer factory with sessionTransacted = true. What I want to do is
When we get a RunTimeException I want to retry the specific message specific no of times(lets say x)
When we get cannot get jdbc connection I want to shutdown the system and want to make sure that this message is sent back to the queue to be redelivered the next time system is brought up.
What I am facing is
When I am setting sessionTransacted as true and I am throwing a RunTimeException the message is redelivered indefinitely . How can I set this configuration to redeliver the message only x times.( I have tried using message header property JMSXDeliveryCount but that does not give me the correct no of times a specific message is redelivered.)
I tried shutting down the system using System.exit(1) but this leads to deadlock and application hangs. I added another piece of code where I am shutting down the application in a different thread and making sure if in between the shutting down of the container another message is read by the listener I throw a RunTimeException so that I am able to get that message again once my system is brought up. However what I want is the 1st message for which we did not get the jdbc connection to be redelivered and no other messages to be read when I stop the container.How can we achieve this.
We have recently migrated our EJB 2 application to EJB 3.In EJB2 if some failures in onMessage container will be able to do retry the message on configured number of times however in EJB3 there is no such option.Could someone help on this.
Can we explicitly sleep the thread and do explicitly retry in onMessage?
Thanks in advance .
If you are using #TransactionManagement(value=
TransactionManagementType.CONTAINER) that is container managed
transaction then on exception, message will be retired 10 time
before the message is send to the DLQ.
If you are not using Activemq RA then, following two documents can
be useful to you if you are having Container-Managed Transaction
Redelivery and Exception Handling and Managing Rolled Back,
Recovered, Redelivered, or Expired Messages
If you are using ActiveMq resource adapter, use can use
MaximumRedeliveries Resource Adapter properties
Else, if you want to retry only on specific exception then you can
catch the exception and then send the message back to the same queue
and with this additional property. Activemq consume message after
delay interval Also, set the retry count in the message header
so that you can keep the track of the retries.
I'm upgrading our application to MQ7 (7.5.0.5) and I'm seeing some odd behavior in a small test application that I have written.
My application uses Springs CachingConnectionFactory and is configured to use only one thread.
I can see that by debugging through the code 2 tcp connections are created, one for the initial connection and one for the JMS session. Every 60 seconds, the 2 tcp connections that are used by my message sink are broken and replaced with 2 new connections.
The following error is present in the error logs on the queue manager.
05/16/2016 09:38:26 AM - Process(1609.14) User(mqm) Program(amqrmppa)
Host(xxxxxxxxx) Installation(Installation1)
VRMF(7.5.0.2) QMgr(xxxxx)
AMQ9271: Channel 'XX.XXXX.X' timed out.
EXPLANATION:
A timeout occurred while waiting to receive from the other end of channel
'XX.XXX.X'. The address of the remote end of the connection was '57.4.4.145'.
ACTION:
The return code from the (recv) [TIMEOUT] 60 seconds call was 0 (X'0').
Record these values and tell the systems administrator.
I have the following settings on my channel: DISCINT(60), SHARECNV(1), the exceptions are linked to the DISCINT time, changing that changes the frequency of the exceptions, also the
exceptions disappear with a SHARECNV value >1
Can anyone tell my why the connections are broken even when the channel is active and messages are being sent and received?
Thanks!
This sounds like APAR IV62728 which describes the symptoms you're seeing:
http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg1IV62728
Fixed in 7.5.0.6. Try upgrading to that level and see if it solves the problem.
I managed to find a solution to this issue. When using the CachingConnectionFactory with an underlying IBM connection factory, an initial connection is created in a stopped state. That connection in then used to create JMSSessions.
The issue was that the initial common connection was timing out.
I managed to keep the connection active by adjusting the HBINT value to 5. It appears that a number of heatbeats are required to keep the connection open and my initial value of 20 was too high.
I have a route which looks like the following:
from("seda:in")
.routeId("aggregation")
.process(filterProcessor)
.aggregate(header("flag", new MyAggregationStrategy())
.completionInterval(10000)
.multicast()
.to(sftpUris);
I'd like to be able to access the producers for each of the URIs in the to clause and check the status of the SFTP connection.
So far I haven't worked out a way of doing this for single (non-multicast) producer, so solutions to that would be useful as well.
According to the Camel docs, you should look at the CamelFtpReplyCode header (and perhaps CamelFtpReplyString) to determine what happened with the request. By default, FTP errors do NOT raise an exception.
I'm using the IA92 Java implementation for MQTT, which allows me to connect to a MQTT broker. In order to establish the connection, I'm doing something like this:
// Create connection spec
String mqttConnSpec = "tcp://the_server#the_port";
// Create the client and connect
mqttClient = MqttClient.createMqttClient(mqttConnSpec, null);
mqttClient.connect("the_id", true, 666);
The problem is that sometimes the server takes too much time to send a response, and it throws a timeout exception:
org.apache.harmony.luni.platform.OSNetworkSystem.connectStreamWithTimeoutSocket(OSNetworkSystem.java:130)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(PlainSocketImpl.java:246)
at org.apache.harmony.luni.net.PlainSocketImpl.connect(PlainSocketImpl.java:533)
at java.net.Socket.connect(Socket.java:1055)
at com.ibm.mqtt.j2se.MqttJava14NetSocket.<init>((null):-1)
at com.ibm.mqtt.j2se.MqttJavaNetSocket.setConnection((null):-1)
at com.ibm.mqtt.Mqtt.tcpipConnect((null):-1)
at com.ibm.mqtt.MqttBaseClient.doConnect((null):-1)
at com.ibm.mqtt.MqttBaseClient.connect((null):-1)
at com.ibm.mqtt.MqttClient.connect((null):-1)
at com.ibm.mqtt.MqttClient.connect((null):-1)
What I need to do is setting a timeout manually, instead of letting the mqtt client decide that. The documentation says: There are also methods for setting attributes of the MQ Telemetry Transport connection, such as timeouts and retries.
But, honestly, I haven't found anything about it. I have taken a look at the whole javadoc reference and there's no evidence of timeout configuration. I can't see the source code since it's not open source.
So how can I set the timeout for the Mqtt connection?
If you have confusion you can go to MqttConnectionOptions for detail.
String userName="Ohelig";
String password="Pojke";
MqttClient client = new MqttClient("tcp://192.168.1.4:1883","Sending");
MqttConnectOptions authen = new MqttConnectOptions();
authen.setUserName(userName);
authen.setPassword(password.toCharArray());
authen.setKeepAliveInterval(30);
authen.setConnectionTimeout(300);
client.connect(authen);
I don't know anything about ia92, but I'd imagine that the 666 in the connect() call is what you're trying to set the timeout to?
The timeout the documentation is referring to is probably the keepalive timeout. This is the maximum number of seconds (chosen by the client) that can elapse without communication between the server and client. I think this is what you're most interested in.
Retries on the other hand are most likely to refer to the retrying of messages that seem to have gone astray when sending messages with QoS>0. This will be something handled by the client library code though, rather than the broker. This is something that comes into play only after you've connected though, so I very much doubt it's your problem.
To be sure that the keepalive timeout is being set correctly, I'd try pointing your client at a modified mosquitto broker. You can modify mqtt3_handle_connect() in src/read_handle_server.c to print out the keepalive value when you connect. This will ensure it's doing what you think, but won't help with the actual problem I'm afraid!
What broker do you use? Really Small Message Broker V1.1 Alpha, Mosquitto, the broker that comes with IBM WebSphere? You need to set this timeout value in your server configuration. Because the system works that way. You set a keep alive value in your broker and send a ping from the client before that interval expires, in order not for the broker to close the client-server connection, and the process restarts. Actually, even if that interval expires, server will still not close the connection until the 'grace period' ends. See http://public.dhe.ibm.com/software/dw/webservices/ws-mqtt/mqtt-v3r1.html#connect