Hello,
we have the following problem:
we have a client that is sending messages to WM JMS server, it is working, the connection is using QCF, we just need to add SSL.
For that matter a different QCF was created for us, which should redirect to the correct url nsps://85.248.235.253:8999
That IP and port should be reachable, telnet goes through.
But we are getting this message and no connection attempt to 8999 were detected, only to the QCF which is at the same address but port 9000.
Thanks for help in advance,
Igor
javax.jms.JMSException: com.pcbsys.nirvana.client.nRealmUnreachableException: Realm is currently not reachable:Realm was still unreachable after max retry count - 2 : nsps://85.248.235.253:8999
at com.pcbsys.nirvana.nJMS.ConnectionImpl.init(ConnectionImpl.java:269)
at com.pcbsys.nirvana.nJMS.QueueConnectionFactoryImpl.createQueueConnectionImpl(QueueConnectionFactoryImpl.java:183)
at com.pcbsys.nirvana.nJMS.QueueConnectionFactoryImpl.createQueueConnectionImpl(QueueConnectionFactoryImpl.java:173)
at com.pcbsys.nirvana.nJMS.QueueConnectionFactoryImpl.createQueueConnection(QueueConnectionFactoryImpl.java:80)
at com.progress.messaging.jms.QueueSessionContainer.createConnection(QueueSessionContainer.java:99)
at com.progress.messaging.jms.SessionContainer.init(SessionContainer.java:303)
at com.progress.messaging.jms.JmsConnection.<init>(JmsConnection.java:39)
at com.progress.messaging.jms.jms._connect(jms.java:323)
at com.progress.javafrom4gl.implementation.JavaServlet.<init>(JavaServlet.java:81)
at com.progress.javafrom4gl.implementation.ServiceImpl.createConnectionServlet(ServiceImpl.java:106)
at com.progress.ubroker.broker.ubServerThreadIPC.write(ubServerThreadIPC.java:433)
at com.progress.ubroker.broker.ubASserverThread.processConnect(ubASserverThread.java:574)
at com.progress.ubroker.broker.ubServerThread.processEvent(ubServerThread.java:1210)
at com.progress.ubroker.broker.ubServerThread.mainline(ubServerThread.java:479)
at com.progress.ubroker.broker.ubServerThread.run(ubServerThread.java:356)
Caused by: com.pcbsys.nirvana.client.nRealmUnreachableException: Realm is currently not reachable:Realm was still unreachable after max retry count - 2
at com.pcbsys.nirvana.base.clientimpl.singleconnection.ClientConnectionManagerImpl.initialise(ClientConnectionManagerImpl.java:399)
at com.pcbsys.nirvana.client.nSession.init(nSession.java:294)
at com.pcbsys.nirvana.client.nSession.init(nSession.java:228)
at com.pcbsys.nirvana.nJMS.ConnectionImpl.init(ConnectionImpl.java:239)
... 14 more
Caused by: com.pcbsys.nirvana.client.nRealmUnreachableException: Realm is currently not reachable:Retry count=1 exceeded attempting to connect to host - [nsps://85.248.235.253:8999/]
at com.pcbsys.nirvana.base.clientimpl.singleconnection.ClientConnectionManagerImpl.establishConnection(ClientConnectionManagerImpl.java:749)
at com.pcbsys.nirvana.base.clientimpl.singleconnection.ClientConnectionManagerImpl.connect(ClientConnectionManagerImpl.java:560)
at com.pcbsys.nirvana.base.clientimpl.singleconnection.ClientConnectionManagerImpl.initialise(ClientConnectionManagerImpl.java:372)
... 17 more
Actually I thought before its a network problem, but isn’t it rather just a response from WM that such realm doesnt exist at all? So I might have misunderstood the source of this exception.
May be for using SSL the realm should just stay the same, so the QCF definition on the WM side may be wrong then, or?
Hi Feng,
QCF is a connection factory.
I think the problem is that the QCF setting is wrong, its pointing to 8999 while there is no realm at this port. So the exception that encountered doesnt mean there is a network problem as I thought, but just plainly that there is a misconfiguration at the server side.
That is my current opinion about the situation.
i
JMS specifically, when you create a connection factory, this creates an entry in the JNDI table, and when a client connects, they use the JNDI to get the address from there for the connection factory, so the initial UM address specified in the JMS client is for the JNDI. Inside the JNDI and your QCF, this will point to a UM address also - and this needs to point to a valid UM address - typically this is on the same server, but there could be scenarios where you’ve got a single JNDI address (or cluster) and that has connection factories to other clusters/etc.
In your particular scenario it sounds like
JMS Client > UM JNDI (port 9000 / http/nsp)
JMS Client > get the QCF > reads destination (IP:8999)
JMS Client tries to use the QCF, but nothing responds on the QCF address that was returned.
Does your realm server (at ip: 85.248.235.253) have an nsps port defined for 8999 as well as 9000 which you said was at the same address?
Is 8999 protected/denied access by some firewall (hardware or software)?
Sounds like you setup the QCF correctly - have you confirmed that this has the right destination address/port from the JNDI view in enterprise manager?
Hi Dave,
thanks for the reaction, the problem is i don’t control/set up the server side but we will discuss it tomorrow with the responsible person.
But while we are at it, I have some access to their enterprise manager though, but honestly don’t know where to find the QCF definitions there. So far I was only using it to view the queue we are sending to and checking if I can see the messages there. Can you show me please how can I see the QCF there?
At the realm server I see only a realm at port 9000, firewall/network accessibility should be fine, but the point is there is not even a try for an outgoing connection from the client program on our AIX server side.
Should there be such connection attempt even if the UM address would be invalid?
Also double check your QCF in the JNDI to make sure that connection URL is correct by double clicking on the connection factory from the JNDI tab. Whats in here will need to be addressable from clients. (my server is only local so yours definitely shouldn’t say localhost, or 127.0.0.1!)
The client that is sending into the queue is Openedge 11.7.5 running on AIX 7.2.
Without SSL it worked - it uses Openedge + WM classes, the thing we configure is AdminObjectFinder.class that basically defines the connection properties.
When trying to switch to SSL besides exchanging the certificates we changed the provider url, allowed the connection to the given port on firewalls on both sides and set value of some new connection properties nirvana.ssl.*
Actually regarding the java code in AdminObjectFinder.class I have some question, may be the problem could be also there, the setting of Content stayed the same - we set INITIAL_CONTEXT_FACTORY and PROVIDER_URL.
The setting of Properties though, there except those nirvana.ssl* properties are also two:
java.naming.factory.initial
java.naming.provider.url
They both need to have the same values like INITIAL_CONTEXT_FACTORY and PROVIDER_URL?
Cos atm the java.naming.provider.url in properties we have is empty…
Edit: But even when I tried setting java.naming.provider.url to the same value as PROVIDER_URL, no change in behaviour.
I think the values INITIAL_CONTEXT_FACTORY and PROVIDER_URL are correct, the same as we had in the non-SSL solution. Just the QCF name changed.
java.naming.factory.initial has the same value like INITIAL_CONTEXT_FACTORY (it is com.pcbsys.nirvana.nSpace.NirvanaContextFactory)
but the question may be is that java.naming.provider.url property - so far I tried empty and also the same as PROVIDER_URL (which is the url where we find either QCF and that is nsp://85.248.235.253:9000).
Just the question is java.naming.provider.url - first I had it empty, now I tried the same value as PROVIDER_URL.
Other options are to set it to nsps://85.248.235.253:8999 or even nsps://127.0.0.1:8999 but somehow it makes no sense to me, because this is defined in the QCF so shouldnt be constant from the view of the client.
Actually I have noticed now that between the definitions of QCF for non-SSL an for SSL there is a difference in this checkbox: Allow for InterRealm, may be this could be the cause - also in the screen from Dave its ticked.
Interrealm is typically for cluster communications in a highly available deployment. You can use this to have a dedicated port for cluster communications versus message traffic.
Have you tried the JMS client code first without SSL?
Yes so far it is working without SSL and now the next task is to implement SSL, for non-SSL we were using a different QCF.
Dave, please can you tell me what should be in our case set in the property java.naming.provider.url?
This is the JNDI information/address, so a connection URL to the UM should work whatever port this is on:
I just pulled the view from the IS setup screen for JDNI for UM - I haven’t got an SSL setup to test against right now, but you can see the values I have and the extra SSL properties. This connects to the JNDI on any active port (of the two I defined in Enterprise manager (docker-ip just to make it a little more complex ).
If you have this working via non-SSL, then I expect it’s SSL related issues as to why it’s not working now.
I.e. assuming everything SSL wise is setup, the JNDI provider URL could be either the nsp, or the nsps port in reality.
).
