I have a problem with a DIIOP connection to Domino but I’m not really familiar with the whole DIIOP story. (I’m an infrastructure guy, not development).
A J2EE server connects to Domino located behing a firewall. Appearantly, the J2EE server crashes since a lot of threads time out. Appearantly, Domino answers its DIIOP requests to no specific port. Since the firewall blocks them (from Domino → J2EE), it takes a while untill the J2EE server gets an answer back on the standaard 63148 port.
Can’t I tell Domino that it should send its answers to one specific port?
Subject: Connection to Domino via DIIOP crashes J2EE server
Not sure if it’ll help or not but as of R6x, a port can now be specified when establishing a CORBA connection to the notes server. For example, String astrIP = new StringBuffer(32).append(“127.0.0.1”).append(“:63148”).toString();
this.nsess = NotesFactory.createSession(astrIP, “some user name”, “some user password”);
With no port specified, it seems to depend on the HTTP server task. Using the port has made for more reliable connections in my experience.
Subject: RE: Connection to Domino via DIIOP crashes J2EE server
Excellent thread on that other site, benpoole. I found especially interesting the note:“DIIOP on Linux and LAZY programmers: default DIIOP port on Linux is 60148, not 63148” I’ll be looking for more on that. Thank you.
(Linux only) Determines whether or not to ignore port limits so the default DIIOP ports 63148 and 63149 can be used. Some Linux systems set port limits that do not allow use of the usual defaults for DIIOP:
1 - Ignore limits; use ports 63148 and 63149
2 - Honor limits; use ports 60148 and 60149
In R5 this variable was called DIIOP_IGNORE_PORT_LIMITS which is still valid for backwards compatibility.
Subject: RE: Connection to Domino via DIIOP crashes J2EE server
Thanks for the discussion reference. I think you’re right on the money. The file is diiop_ior.txt. If the HTTP task happens to hang for whatever reason and you haven’t specified the port in your connection, you won’t get one. And in my experience, restarting the HTTP task won’t do it either. HTTP and DIIOP both have to be stopped and restarted in that sequence (ie, HTTP first, then DIIOP).