NameServer Access

WebSpeed Essentials

Running and Deploying WebSpeed Applications : Firewall configuration and debugging : Debugging firewall configurations : NameServer Access

NameServer Access

If the Messenger is working, the next step is to confirm that the NameServer is being accessed. Set the NameServer's logging level to 3 (Verbose) using OpenEdge Management/OpenEdge Explorer or by editing ubroker.properties manually. To enable this change, you must stop and restart the NameServer and wait for the WebSpeed broker to inform the NameServer that it is available.

If the NameServer does not know about a service, it cannot direct clients to it. To check the NameServer to see if it knows about the WebSpeed server, you can use OpenEdge Management/OpenEdge Explorer or you can use the code NSMAN -name NS1 -query, as shown in below.

Checking NameServer access using NSMAN -name NS1 -query

C:\>nsman -name NS1 -query
OpenEdge Release 10.0B as of Tues Apr 27 00:31:00 EDT 2004

Connecting to Progress AdminServer using rmi://localhost:20931/Chimera (8280)
Searching for NS1 (8288)
Connecting to NS1 (8276)

NameServer NS1 running on Host nexus Port 5162 Timeout 30 seconds.
Application Service UUID Name Host
Port Weight Timeout

WS.Sports2000_WS
527a0623fe008210:67d940:f6484c1312:-7d87 WS.Sports2000_WS
nexus/192.168.123.121 3055 0 30

Now, try to access the application again. After the error is returned to the WebSpeed Messenger, check the NameServer's log file. You should see something similar to the following:

Thread-0>(26-Jul-03 18:42:15:107) Request received from 192.168.123.110 2167
for WS.Sports2000_WS. (8201)
Thread-0>(26-Jul-03 18:42:15:107) AppService = WS.Sports2000_WS Found = true
Number Of Brokers = 1. (8206)
Thread-0>(26-Jul-03 18:42:15:107) Response sent to 192.168.123.110

If you do not see the "Request received" in the log file, then the firewall is losing the inbound NameServer request. Otherwise, the outbound request is being lost. After debugging this stage, make sure to reset the logging setting.