Skip to Content

Information Re: Server IP Binding Check Alert

Apr 16 at 11:04 PM


avatar image

I recently applied Lumira Server 2.1 patch on 4 servers in my cluster, plus the Lumira Server 2.1 full install on a new node in the cluster.

Ever since this, the system has been slow, the Log Out button sits at "The cleanup is in progress. Wait... and Lumira documents do not open in Launchpad, nor does the Lumira Discovery application.

I ran a report in BIPST, and the "Server IP Binding Check" is now alerting on both of the processing nodes in the cluster. I manually reviewed each server in each of these nodes and all of them still have the Request Port assigned so I'm confused why this alert is triggering.

I have a suspicion that this alert may be tied to all of the other problems I'm having- the logout hang is mentioned in note 2422930 and here it mentions that you need to assign request ports. But again I have validated all servers have request ports.

Can you provide more insight into what exactly this alert is looking at so that I may continue to troubleshoot how to resolve this alert, and potentially fix all of the other issues in my landscape?

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

2 Answers

Best Answer
Leslie Mui
Apr 17 at 04:10 PM

Hi Brian,

Specifically, the alert takes the address that each server on a node is bound to and compares them. If any servers are found to be bound to different hosts, the alert is thrown.

I think the easiest way to check is to head to landscape tools -> Communications analyzer, and execute the test against a landscape.

Export the result to excel, and then in the Decoded IOR column, compare the host: property for servers that did/didn't throw the alert.


Show 2 Share
10 |10000 characters needed characters left characters exceeded

Thank you Leslie. I appreciate the info.

I see the difference, some servers have the host name as the base host name, others have the FQDN.




Those with just the base server name do have an alternate IIOP address #1, which lists the host as the FQDN with the same request port.

Any indication on how this would have happened in my clustered landscape, and what I need to do to fix, or if I need to fix it?


I'm not sure if it's something that needs looking into. I think that provided all servers in the node can find the other servers by both FQDN and hostname through DNS, there isn't an issue.

I'm going to hazard a guess that it might be something to do with how we perform the binding with Java based servers vs native code servers.

The primary purpose of the alert is for multi-NIC machines, and ensuring that all BOBJ servers on a node bind to the same NIC.


Toby Johnston
Apr 17 at 04:09 PM

Hi Brian,

The alert checks that all servers on a particular node are binding to the same IP address. Is the host you are running the processing nodes on a multi-homed machine? In otherwords, does it have more than one IP address?



10 |10000 characters needed characters left characters exceeded