Sporadic access to both OE Explorer and Apache Tomcat Web Se

Mmmm...more on this.

I found this reference which points to an issue with 32bit on my 64bit machine.  I do have a Sony Vaio as per this guy's situation.  Could this MySQL issue have anything to do with my Progress issue?

http://www.webdevelopersnotes.com/blog/mysql-windows-7-64bit-installation-with-apache-and-php/

Also, I might explain that Apache Tomcat is the Web Server application referenced in the Progress Web Services Course guide.  I understood by this that it is the recommended software.

:-(

Hello,  There seems to be many issues here.  Let me give you some suggestions on OpenEdge Explorer.  You should be able to access OpenEdge Explorer from your web browser as well as from Architect.  What error do you get when you accessing http://localhost:9090/ ?  Are there any errors is the admserv.log file? Are there any exception log file in the directory? (check the working directory of the OpenEdge install)  There may be many things here, settings on the Windows firewall, conflict between TCP ports, or some exception.  I hope this helps.

@egarcia

What error do you get when you accessing http://localhost:9090/ ?..... Message is "Google Chrome could not connect to localhost:9090"

Are there any errors is the admserv.log file?  Firstly there seems to be nothing sinister in admserv.log...but looking through the Apache log directory there is a message in stdout.log that says "WSA (Sheffield_wsa): WARNING cannot access library environ.dll. The ubroker.properties token replacement is disabled."

This sounds suspicious...unfortunately I'm not familiar with the file except to know that it's connected with Sonic.

*Attached is a log from asbroker1.server...two errors appear there but probably unconnected to the OE Explorer issue.

*Attached is a log for Sheffield_wsa.wsa.log...it shows that for some reason after successfully deploying and enabling the PartsSystem service at 10/07/05@10:54, the request to login as "Progress" is denied access to administration operation. The Apache tomcat-users.xml file is also attached showing manager privilege assigned to user Progress.

Definitely struggling here.

Steve

Hello,

What error do you get when you accessing http://localhost:9090/ ?..... Message is "Google Chrome could not connect to localhost:9090"

This error message indicates that the web server for OpenEdge Explorer is not running.

OpenEdge Explorer is started as part of the startup of the AdminServer unless that the access to OpenEdge Explorer has been disabled.

It would help to check that the AdminServer is running. You can use Process Explorer from Windows Sysinternals to show the processes that are running and get more information from it.

In this case, the AdminServer seems to be running since it is the one that starts the AppServer and the other server processes listed in the ubroker.properties.

With Process Explorer, check that there is a Java process with TCP/IP properties (do right click or alt-enter on the process) that shows a listening socket at TCP 20931. This is the AdminServer.

This process should also have a listening socket at TCP 9090. (You should see TCP and TCPV6)

In the admserv.log file, check for an entry like:

[6/29/10 8:05:31 PM] [3] [Fathom]                Starting Fathom WebServer. (10144)

[6/29/10 8:05:32 PM] [3] [Fathom]                Listening for HTTP connections on port 9090

This will tell if OpenEdge Explorer is being started as part as the AdminServer.

Take also a look at the file %DLC%\properties\fathom.properties. This file has properties that indicate whether OpenEdge Explorer is started automatically (autostart=true) and also the port number for the web server (httpport property).

If there are Java exceptions, a file named ads0.exp would be present in the working directory for the AdminServer.

I am not very familiar with the WSA configuration but it seems that the warning message about environ.dll happens because the environ.dll has already been loaded by the Tomcat server and the dll is locked. This may just be a warning and not something that may cause a problem.

I would not expect error (10972) to list the user name in the way that it does in the wsa.log file. I would only expect to see the name of the user. Technical Support may provide some information on this.

It seems that you have Apache Tomcat 64-bit installed using the installer. Has this installation worked before? When did the issue start happening?

As a way to troubleshoot this, I wonder what happens if you try Apache Tomcat installed using the zip file then configure it with the OE_TC.bat file.

I hope this gives you some ideas.

Regards.

@egarcia

Thanks for all the info...I spent some time going over the logs and processes and here's what I eventually found.

The fathom setup script for Tomcat 5.5 (bin/OE_TC) doesn't work with Tomcat 6.0.  There is another directory layer in T5.5 that doesn't exist in T6 (called conf/server).

I downloaded and installed Tomcat 5.5 and then ran the OE-TC script...this ran without any problems.

I shutdown the PC completely (power off) and rebooted.

I started the Apache service.

Would you believe OE Explorer came up first time from the Start Programs menu...wonderful.

Twenty minutes later Windows 7 spat the dummy again and froze on me, requiring a cold boot...I restarted Windows normally.

I started the Apache service.

Guess what?  Attempting to reach OE Explorer by any means came up with the 'Google Chrome could not connect to localhost:9090' again!! Back to square one!!!

I thought I'd take a look at the running processes looking for any rogue ones.  I began by stopping the Apache service, followed by the OE Admin service. I saw three processes that I thought shouldn't be there...

_dbagent.exe

_mprosrv.exe

_mprshut.exe

plus 3 active java processes owned by OpenEdge.

I killed them all.  Restarted the OE Admin and the Apache Tomcat services.  After a few seconds delay, the three .exe's reappeared with one java process.

...and OE Explorer this time worked!!

Not to be fooled by co-incidence I stopped the OE Admin service to see if the 3 processes disappeared. They stayed!!  A new OE Admin service appeared in the process list and an attempt with OE Explorer failed with the same error as before. I stopped and started the Admin service a few times with the same result.

Killing what I now think must be orphan processes and restarting the OE Admin service gave me a 100% success rate in getting back into OE Explorer.

So here is what I have deduced.  Under some circumstances, when OE Admin is stopped, orphan processes remain and it is the existence of these, or tokens that they manage, that prevents OE Explorer from waking up from port 9090.

I think a little root cause analysis by Progress will find why this is so.

Many thanks for your help...it was most useful.

Cheers

Steve

This is answered in so far as the workaround meets with success 100% of the time. However, there needs to be a root cause analysis (a PROBLEM ticket in ITIL terms) raised to remove the problem.

Steve