Develop Reference

JMS - Couldn't create session factory even if connection to remote provider is OK

I make a jar to connect to JMS provider, it's work fine in a server (a) but doesn't work on a server (b).
I verify that connection to the JMS provider from server (b) is OK via telnet as shown below:
-> telnet -d 10.127.161.247 4447
Trying 10.127.161.247...
Connected to 10.127.161.247.
The logs and exception that it's throw is below :
2018/08/01 11:19:47:921 - Processing command line arguments...
2018/08/01 11:19:47:927 - Preparing the output... Writing to file = true
2018/08/01 11:19:50:315 - Trying to establish connection, attempt: 0
2018/08/01 11:19:52:132 - Connecting to provider: remote://10.127.161.247:4447 using user: oad_user
2018/08/01 11:19:52:132 - Creating a regular (non-secure) connection factory...
2018/08/01 11:19:53:073 - Opening a connection to the JMS provider...
2018/08/01 11:20:24:192 - Attempt failed: Failed to create session factory
javax.jms.JMSException: Failed to create session factory
at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:675)
at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createTopicConnection(ActiveMQConnectionFactory.java:267)
at com.alcatel.ossgw.client.jms.JmsSubscriberClient.prepareConnection(JmsSubscriberClient.java:334)
at com.alcatel.ossgw.client.jms.JmsSubscriberClient.connect(JmsSubscriberClient.java:274)
at com.alcatel.ossgw.client.jms.JmsSubscriberClient.listen(JmsSubscriberClient.java:97)
at com.alcatel.ossgw.client.jms.JmsSubscriberClient.main(JmsSubscriberClient.java:536)
Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:818)
at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:67
I don't how to debug such a problem knowing i'm new in JMS, i'll be grateful for any remarks and ideas..
Many thanks

Did you ever find out why this was happening?
I have a related issue where an active JMS connection suddenly disconnects and the system starts throwing this exception until a system restart is done and then it connects again without fail.

javax.jms.JMSException: Cannot send to a non-connected transport

I am using the qpid-jms-client.jar library to form a connection with a broker.
My code is ::
Properties properties = new Properties();
properties.load(this.getClass().getResourceAsStream("jndi.properties"));
Context context = new InitialContext(properties);
System.setProperty("javax.net.ssl.trustStore", "C:/Users/xxxxx/qpid.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "test123");
ConnectionFactory factory = (ConnectionFactory) context.lookup("myFactoryLookup");
Destination queue = (Destination) context.lookup("myQueueLookup");
Connection connection = factory.createConnection("<my-username>", "<my-password>");
connection.setExceptionListener(new MyExceptionListener());
connection.start();
My jndi.properties file is ::
java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory
connectionfactory.myFactoryLookup=amqps://esesslx0100.se:9443
queue.myQueueLookup=emft_input
topic.myTopicLookup=topic
destination.topicExchange=amq.topic
jms.user=test
Now the above code gives me the ERROR ::
Connection ExceptionListener fired, exiting.
javax.jms.JMSException: Cannot send to a non-connected transport.
at org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:66)
at org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:88)
at org.apache.qpid.jms.JmsConnection.onAsyncException(JmsConnection.java:1188)
at org.apache.qpid.jms.JmsConnection.onConnectionFailure(JmsConnection.java:1104)
at org.apache.qpid.jms.provider.amqp.AmqpProvider.fireProviderException(AmqpProvider.java:847)
at org.apache.qpid.jms.provider.amqp.AmqpProvider.pumpToProtonTransport(AmqpProvider.java:820)
at org.apache.qpid.jms.provider.amqp.AmqpProvider.access$300(AmqpProvider.java:90)
at org.apache.qpid.jms.provider.amqp.AmqpProvider$16.run(AmqpProvider.java:683)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Cannot send to a non-connected transport.
at org.apache.qpid.jms.transports.netty.NettyTcpTransport.checkConnected(NettyTcpTransport.java:279)
at org.apache.qpid.jms.transports.netty.NettyTcpTransport.allocateSendBuffer(NettyTcpTransport.java:176)
at org.apache.qpid.jms.provider.amqp.AmqpProvider.pumpToProtonTransport(AmqpProvider.java:806)
... 9 more
Since the broker is configures with SaSL, I am also providing my username and password. I am currently unaware of why this ERROR occurs. Ive looked around on the internet but there is no clear explanation as to why it would occur with qpid. Any ideas why this ERROR occurs ?
My trustStore file is correct since I have verifies SSL connectivity using it.

Turning up the clients logging might give some more trace/debug information. Both the 'regular logging', and 'protocol trace logging' (if it even gets that far) might be useful. See http://qpid.apache.org/releases/qpid-jms-0.22.0/docs/index.html#logging for more details.
To the issue here, where it seems the TCP connection is being cut, the server logs could also perhaps be useful in giving a reason.
You dont mention which server you are using here, but have mentioned ActiveMQ and RabbitMQ in other related questions. Its unclear how far the connection gets, but if the server is RabbitMQ, one potential explanation might also be: https://github.com/rabbitmq/rabbitmq-amqp1.0/issues/47. As mentioned in another answer, this may not matter due to other issues, e.g. I didn't have much success using the JMS client or some other AMQP 1.0 clients against RabbitMQ previously due to an issue I reported which stops them in their tracks when creating consumers and producers: https://github.com/rabbitmq/rabbitmq-amqp1.0/issues/34

Thanks for all your replies. In my case turns out all the libraries/configurations I was using were indeed correct. I contacted the team that manages the broker. Turns out the user I was trying to connect with had some PRIVILEGE issues. As soon as they gave my user the correct rights, I was able to form a successful connection and transmit and receive messages.

In my case when receiving this error it was simply because when I was in the office our company proxy was filtering this traffic out when I executed programatically. Using Service Bus Explorer still worked though as it must have picked up machine settings that add the proxy.
We were using a publicly hosted Service Bus so I attempted from my home network without the proxy and everything worked as expected. Using Wireshark or similar program probably would have helped identify this quicker. Hope this helps someone.

This line shows your error:
Caused by: java.io.IOException: Cannot send to a non-connected transport.
That's saying your connection is configured incorrectly. One thing I see is that your're not referencing the properties in your property file. For example,
this:
ConnectionFactory factory = (ConnectionFactory) context.lookup("myFactoryLookup");
Destination queue = (Destination) context.lookup("myQueueLookup");
Should probably be this:
ConnectionFactory factory = (ConnectionFactory) context.lookup("connectionfactory.myFactoryLookup");
Destination queue = (Destination) context.lookup("queue.myQueueLookup");

Recovery of the connection in RabbitMQ for Clustered environment

I'm trying to recover the connection in RMQ for Clustered environment but unfortunately i'm not able to recover it in code and its also not catching in my exception.
For example. Initially node 1 is connected and our messages has been flow successfully and to test fail-over, we brought up node 2 and stopped node 1.. connections are being lost which is expected, but retry is not happening as node 2 is up.
When i restart my service, i'm able to get exception as:
"Rabbit MQ Message Exception : Error = 'connection is already closed due to
connection error; cause: java.net.SocketException: Connection reset'"
Can anyone please suggest how to recover it in such case?
Have used below configurations in my code. (AMQP client):
factory.setAutomaticRecoveryEnabled(true);
factory.setNetworkRecoveryInterval(5000);
factory.setTopologyRecoveryEnabled(true);
factory.setRequestedHeartbeat(60);
By using Lyra connection recovery will occur with following config:
.withRetryPolicy(new RetryPolicy()
.withMaxAttempts(30)
.withInterval(Duration.seconds(1))
.withMaxDuration(Duration.minutes(5)));

Failed to connect to queue manager 'QUEUE-NAME' with connection mode 'Client' and host

I have developed subscripe (topic) conncept using Camel. it is working fine in my local tomcat.but it is not working in my test environment tomcat. it is getting below mentioned error. kindly help me to resolve the issue and how to debug the issue.
is it related to server configuration ?
Error
org.apache.camel.component.jms.JmsMessageListenerContainer refreshConnectionUntilSuccessful
SEVERE: Could not refresh JMS Connection for destination 'TOPIC-NAME' - retrying in 5000 ms. Cause: JMSWMQ0018: Failed to
connect to queue manager 'QUEUE-MANAGER' with connection mode 'Client' and
host name 'HOST-NAME'.; nested exception is com.ibm.mq.MQException:
JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED')
reason '2059' ('MQRC_Q_MGR_NOT_AVAILABLE').
regards,
Gnana

There is almost no information to go on here and therefore no way to answer with any confidence. Instead, I'll provide a diagnostic process and hopefully you will find the problem. Note that in the future if you have similar issues, it would help to list the diagnostics you have already tried so that people responding can narrow down their answers.
In order for this to work, the QMgr must be running a listener, have a channel defined and available, have authorizations set up to allow the connection, and be able to resolve the queue or topic requested. With that in mind, the things I normally check and the order I check them in is as follows:
Is the QMgr running.
Is the listener running? On what port?
Can I telnet to the QMgr on the listener port? i.e. telnet mqhost 1414.
Is the channel defined? If so, is it available?
Do the sample client programs work? In this case, amqspubc is the one to try.
There are other considerations and if all of the above work, it is time to look into the client code and configuration, the versions of the client and server, authorizations, etc. But until you know that the basic configuration is in place to support a client connection (which was not indicated in the question) then these are the things to start with.

Jms Broker connection - Test the connection before listening to the queue - java

We have a message listener that listens to the Queue configured. When the Message broker is stopped or down, the application exits abruptly. Is there way to check the JMS broker connection before listening to the queue. The listener code must be enabled only if the JMS Broker is up. We are getting the below exception when we listen to the Queue (with the JMS broker down)
org.springframework.context.ApplicationContextException: Failed to start bean 'xx'; nested exception is org.springframework.jms.UncategorizedJmsException: Uncategorized exception occured during JMS processing; nested exception is javax.jms.JMSException: Could not connect to broker URL: tcp://xx:61616. Reason: java.net.ConnectException: Connection refused: connect
at org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:176)
at org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
at org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:346)
at org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:149)
at org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:112)
at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:773)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.finishRefresh(EmbeddedWebApplicationContext.java:142)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:485)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.refresh(EmbeddedWebApplicationContext.java:120)
at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:691)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:320)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:952)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:941)

you can not test your connection to be active, as whenever you setup connection with activemq it only succeeds if you have an activemq server running.
A good option can be to do it in Java code by handling 'connection exceptions' and trying to re-connect after specific intervals till no exception occurs.This will help in scenario where ActiveMQ is down before you try and setup connection with it.
Hope it helps,
Good Luck!

Use the failover transport in your clients: failover:(tcp://host:port?TCP_OPTIONS)?FAILOVER_OPTIONS
When the connection isn't available (via the inner TCP transport), the failover transport will continue retrying until it is available and then establish the connection and let your client proceed as normal. This will look like the client is hung, but it's just waiting for the broker to become available before continuing. This configuration will also try to re-connect if the connection is broken for some reason (e.g. you restart your broker).
Most people use the failover transport to allow you to connect to whichever broker out of a group of N is available, but it's completely fine to use it with just one inner TCP transport; it will still try to reconnect periodically whenever it fails to connect to the single TCP transport.