Connection to WM - nRealmUnreachableException

iec · December 11, 2020, 10:52am

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

iec · December 11, 2020, 1:32pm

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?

Feng_Sian5 · December 12, 2020, 8:24pm

Hi Igor,
would you mind clarifying what QCF stands for?

Have you attempted to connect using the Universal Messaging Enterprise Manager? Can you share the outcome?

iec · December 13, 2020, 9:37am

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

Dave_Pemberton · December 14, 2020, 9:13am

Igor, you’re correct.

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?

iec · December 14, 2020, 1:17pm

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?

Regards,
Igor

Feng_Sian5 · December 14, 2020, 2:27pm

My 2-cents contrib (now that I know what QCF stands for), let me share where to find the QCF definition:

open the Universal Messaging Enterprise Manager.
connect into the realm.
click on the realm.
click on the JNDI tab.

image958×87 12.5 KB
and search the QCF. Mine is ‘um.ConnectionFactory’. Just a name.

iec · December 14, 2020, 2:46pm

OK thank you Feng, I see the QCF now.
Now possibly the cardinal question is from the post of Dave:

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?

How can I check this? What does it mean?
And where can I see that it is SSL enabled etc.

Regards,
Igor

iec · December 14, 2020, 2:49pm

Probably this?
Is it correctly set?

Dave_Pemberton · December 14, 2020, 3:22pm

That looks correct - there’s an NSPS port on 8999!

Take a look at the comms tab to see the nsps port:

Have a look at the ‘Basic’ tab to ensure this allows client connections.

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!)

iec · December 14, 2020, 3:29pm

Everything seems fine:

So why does my client application generate realm is unreachable exception without any attempt for outside connection to port 8999 then?

iec · December 14, 2020, 3:40pm

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.*

Regards,
Igor

iec · December 14, 2020, 4:19pm

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.

Feng_Sian5 · December 14, 2020, 5:06pm

Have you tried

   INITIAL_CONTEXT_FACTORY=<the_same_QCF_name_you_found_in_the_JNDI_tab>
   PROVIDER_URL=nsps://127.0.0.1:8999

iec · December 14, 2020, 5:15pm

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.

iec · December 14, 2020, 5:24pm

Basically I am referring to this:

But not sure what to set as rname in this case.

iec · December 14, 2020, 5:30pm

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.

Dave_Pemberton · December 14, 2020, 7:28pm

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?

iec · December 14, 2020, 10:23pm

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?

Dave_Pemberton · December 15, 2020, 10:29am

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.