Open API port problem

Hi,

I am using Open API, port 1099 for communicating with TeamSite. I am facing a peculiar problem, suddenly the Open API is not listening to the above mentioned port.
After resetting the TeamSite Server (i.e.. ./iwreset –a) it works, but only for few minutes. Any help is highly appreciated.

I am using:
TeamSite 5.5.2
Solaris 8

-Rathina

Find more posts tagged with

Comments

Migrateduser

Can you check whether the process - rmiregistry is running? It is this process that listens to OpenAPI requests on port 1099. Also, can you check whether at the time of failure, the process servletd is running?

Are you behind a firewall?

Best Regards,
Narendra

Rathina

Yes its actually behind the firewall.
this problem is coming then and there. its working fine for sometime suddenly the port is not listening. I haven't checked for servletd at that time. but if i reset the teamsite server its working fine. so what will be the problem? Any suggestions is appreciable.

Migrateduser

You should monitor the status of servletd. There is also a log file for this process that you could check.

lissa

Migrateduser

Hi,
OpenAPI uses RMI, and hence, makes use of a large number of anonymous ports (no fixed range, around 100) for communication between the openapi client and the openapi server. Prior to TS5.5.2 SP2 release of openapi, there was a bug, relating to firewalls, wherein there was no provision to restrict the ports that openapi uses to a fixed range.
In 5.5.2SP2 service pack, openapi.cfg has configurable entries for ensuring a fixed port range. The entries are - OPENAPI.rmi_port_number_min and OPENAPI.rmi_port_number_max. What you can do is allow a range of 100 ports that you can allow access to over your firewall. This should fix your problem.

Again, this is available only in service pack TS5.5.2SP2 and above.

Hope this helps.

Best Regards,
Narendra

Rathina

Hi
Here the problem occuring in client environment.
now they are saying that there is no firewall.And also by this time also the problem is there and i checked for rmiregistry and servletd both are not running.so if I get any solution ASAP. It will be very usefull to me.

thanks
Rathina

Migrateduser

OpenAPI server is within the servletd process. If both servletd and rmiregistry are not running, then there is no way openapi will work. You need to check the servlet logs, and see if servletd failed to come up due to some other reason.

Best Regards,
Narendra

Rathina

Hi
Actually I checked the process using ps -ef | grep servletd.
its not running.If there is anyother way to check. I opened the servlet.log which was in
$root/iw-home/servletd/logs/ in that there was no error entry.so i am confused what's happening behind this.

Rathina

Migrateduser

the servlet log is in /var/adm/iwui. Can you check that?

Best Regards,
Narendra

Rathina

Hi
Narendar thanks for ur immediate response.There is no /var/adm/iwui. In /var/adm i saw some message files.
it will work for this thing.And in that root one log folder is there,but inside no files are there.

thaks
Rathina

Migrateduser

I would recommend you file a support case, it sounds like you have a problem with servletd.

lissa

Rathina

HI
See can you suggest if there is anyway to monitor the servletd process and which log file is for process thing.

thanks
Rathina

Rathina

Hi
Here the problem goes like this,we thought that once we reset the teamsite server both the process rmiregistry and servletd is running and port 1099 also listening.but we done the reset also now port is listening,rmiregidry also running but still the servletd is not running.but we are not phasing any problem.application work fine.so here the conflict is is servletd is required for openAPI then how things are working?.Any suggestion is appreciable.

thanks
Rathina

Migrateduser

Hi,
I cannot say offhand what the problem is. This does look like its a problem for Interwoven support. I think you should take Lissa's suggestion and open a problem ticket with Interwoven support.

Best Regards,
Narendra

Migrateduser

did you ever get this issue resolved? we are encountering the same problem after moving out TS server across domains. both services are running however.

any help would be appreciated, thanks