Hi. I'm pretty new to custom web publishing so I used the site assistant to generate a few stylesheets so I could see how it works.

I had site assistant generate all possible pages (insert, update, find, browse, home page, etc.) and for the most part it works pretty well.

However, I randomly get sent to an error page after clicking a link or button. Here's what the error page looks like:

-----------------------------------------------

FileMaker Custom Web Publishing with XSLT

An unexpected error has occurred

File: /fmi/xml/fmresultset.xml

Line:

Column:

Note: If a source file and line number are indicated, this is the location where the error was detected and not necessarily the exact location of the problem.

-----------------------------------------------

There is no pattern that I can figure out. It sometimes happens when I try to edit a record, other times it happens when I try to view the record list, etc. I checked logfile, pe_application_log.txt, and found some entries that might correspond to the error I'm getting. Here's what they all look like:

-----------------------------------------------

[04/May/2005:13:51:26 -0500] XSLT-CWP: An unexpected error has occurred (null) File: /fmi/xml/fmresultset.xml

-----------------------------------------------

If I wait a minute or so and try again it usually works. If I try again too soon I get the error.

Can anybody help me troubleshoot this problem? I don't know what to do.

I don't know the structure of FMS7A on Windows 2000 Server (we have a Mac installation here). In the FMS7A Web-Publishing folder, is there a folder called jakarta-tomcat?

Yes, there is. Here's a list of all the folders contained in the web publishing folder for my installation:

conf

jakarta-tomcat

java

logs

publishing-engine

Setup

tools

web-configuration

xslt-template-files

Ok. My guess is this: This error might come from the fact that the WPE might not respond fast enough to your query and therefore Tomcat returns an error. I could reduce such errors on our web site by tweaking the Tomcat settings, but sometimes they still occur, especially when our internal search engine reindexes our web pages and sends a lot of queries.

You can do a cross check: There should be also an access log file of your web server (probably IIS). Take the time [04/May/2005:13:51:26 -0500] from your pe_application_log.txt and search it in the access log file of IIS. You should see there your query, then two numbers after that, the first being the HTTP status code, the second the length of the HTTP message returned (i.e. length of HTTP header + length of generated HTML file). If the HTTP status code is 200, this would mean OK. If it's 500, this means internal server error, indicative for what I guessed above.

In addition, please post the following here: In your jakarta-tomcat directory, there is a subdirectory conf with a file server.xml . Of this file, please post the line that starts with <Connector. Not the one that is commented, but the second line below.

The corresponding IIS logfile entries all have a status code of 200.

Here's the &ltconnector&gt tag from my conf.xml file:

&ltConnector acceptCount="10" bufferSize="2048"

         className="org.apache.coyote.tomcat4.CoyoteConnector"

         connectionTimeout="0" debug="0" disableUploadTimeout="false"

         enableLookups="true" maxProcessors="75" minProcessors="5" port="16018"

         protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"

         proxyPort="0" redirectPort="8443" scheme="http" secure="false"

         tcpNoDelay="true" useURIValidationHack="false">

         &ltFactory className="org.apache.catalina.net.DefaultServerSocketFactory"/&gt

&lt/Connector&gt

I also tried clicking through the site very slowly (i.e. waiting at least five seconds between clicks) and still experienced the same problem.

Another piece of information that may be related to my problem is that I can't enable database sessions for xslt publishing. In the web console, when I toggle the radio button for database sessions to yes and click the apply button an error message appears at the top of the page. It says "An unexpected error has occurred."

I think I've uncovered some more information. I read some tomcat documentation and figured out how to enable debugging. In the server.xml file, you have to change the verbosity to 4 for the &ltlogger&gt element and change the debug level to a number greater than zero (I used 3) for any component that you want to debug. Anyway, I did that and recreated the error.

Here's what turned up in the logfiles:

----------------

Tomcat log (...jakarta-tomcatlogslocalhost_log.2005-05-05.txt)

2005-05-05 18:25:45 StandardContext[/fmi]: Mapping contextPath='/fmi' with requestURI='/fmi/xsl/quotes/browserecord.xsl' and relativeURI='/xsl/quotes/browserecord.xsl'

2005-05-05 18:25:45 StandardContext[/fmi]: Trying exact match

2005-05-05 18:25:45 StandardContext[/fmi]: Trying prefix match

2005-05-05 18:25:45 StandardContext[/fmi]: Trying extension match

2005-05-05 18:25:45 StandardContext[/fmi]: Mapped to servlet 'FMICustomWebPublishingEngine' with servlet path '/xsl/quotes/browserecord.xsl' and path info 'null' and update=true

2005-05-05 18:25:46 HostConfig[localhost]: Deploying discovered web applications

pe_application_log.txt

[05/May/2005:18:25:45 -0500] XSLT-CWP: An unexpected error has occurred (null) File: /fmi/xml/fmresultset.xml

IIS logfile (timestamp is GMT, system time is -5 GMT)

2005-05-05 23:25:45 192.168.1.104 - 192.168.1.5 8080 POST /jakarta/isapi_redirect.dll - 200 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0;+.NET+CLR+1.1.4322)

----------------

That last message in the tomcat log, "Deploying discovered web applications", seems to always appear a few seconds after I get an "unexpected error" from browsing the site.

I'm not sure if I have led you on the right track, because you did not find any 500 error. But anyway, what I tried out, was the following:

<Connector acceptCount="50" bufferSize="32768" className="org.apache.coyote.tomcat4.CoyoteConnector" connectionTimeout="20000" debug="0" disableUploadTimeout="false" enableLookups="false" maxProcessors="200" minProcessors="50" port="16018" protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler" proxyPort="0" redirectPort="8443" scheme="http" secure="false" tcpNoDelay="true" useURIValidationHack="false">

So I increased the number of queues that accept a query if the threads are occupied, increased the buffersize for those overflow queues, increased the number of possible threads ( maxProcessors, minProcessors), increased the connectionTimeout to 20000 ms (the Tomcat manual even recommends 60000 as default, FMI set it to 0), and set enableLookups to false (this improves performance and does not stress your DNS server). I am not sure if changing connectionTimeout helps, but the change of all the parameters mentioned help that I don't get those 500 errors.

Thanks for turning debugging on. I think path info 'null' is the clue!

Do you think that the FMICustomWebPublishingEngine servlet is misconfigured somehow?

I just repeated the exercise to see what a successful request looks like in the log files when debugging is turned on. Unfortunately, it looks the same.

Here's what a successful request looks like:

-------------

2005-05-06 19:36:04 StandardHost[localhost]: Mapping request URI '/fmi/xsl/quotes/recordlist.xsl'

2005-05-06 19:36:04 StandardHost[localhost]: Trying the longest context path prefix

2005-05-06 19:36:04 StandardHost[localhost]: Mapped to context '/fmi'

2005-05-06 19:36:04 StandardContext[/fmi]: Mapping contextPath='/fmi' with requestURI='/fmi/xsl/quotes/recordlist.xsl' and relativeURI='/xsl/quotes/recordlist.xsl'

2005-05-06 19:36:04 StandardContext[/fmi]: Trying exact match

2005-05-06 19:36:04 StandardContext[/fmi]: Trying prefix match

2005-05-06 19:36:04 StandardContext[/fmi]: Trying extension match

2005-05-06 19:36:04 StandardContext[/fmi]: Mapped to servlet 'FMICustomWebPublishingEngine' with servlet path '/xsl/quotes/recordlist.xsl' and path info 'null' and update=true

-------------

Here's a request that resulted in the 'unexpected error':

-------------

2005-05-06 19:36:06 StandardHost[localhost]: Mapping request URI '/fmi/xsl/quotes/home.xsl'

2005-05-06 19:36:06 StandardHost[localhost]: Trying the longest context path prefix

2005-05-06 19:36:06 StandardHost[localhost]: Mapped to context '/fmi'

2005-05-06 19:36:06 StandardContext[/fmi]: Mapping contextPath='/fmi' with requestURI='/fmi/xsl/quotes/home.xsl' and relativeURI='/xsl/quotes/home.xsl'

2005-05-06 19:36:06 StandardContext[/fmi]: Trying exact match

2005-05-06 19:36:06 StandardContext[/fmi]: Trying prefix match

2005-05-06 19:36:06 StandardContext[/fmi]: Trying extension match

2005-05-06 19:36:06 StandardContext[/fmi]: Mapped to servlet 'FMICustomWebPublishingEngine' with servlet path '/xsl/quotes/home.xsl' and path info 'null' and update=true

-------------

Do you know how to turn on debugging for the FMICustomWebPublishingEngine servlet?

No, I haven't found a way. Sorry.

Problem solved!

I uninstalled FM Advanced server and put it on another computer running Windows 2000 Server. Now everything works fine.

Someday I would like FM Server & FM Advanced Server to live together on one machine but for now I'm happy.

Martin - Thanks for helping me try to solve this problem!

I had the same problem. I found that the error comes from the fact that standard port 80 has been changed. In order to avoid Unexpected Error you have to change back to port 80. I was running apache server. On apache server the port is changed from http.conf file.

We've been having this issues since we installed FileMaker Server 7.

We've had it on MacOSX 10.3 and on Windows 2000 Server. I've played with the connections and threads like Martin has suggested and I've written and rewritten the pages.

I've also paid FileMaker for support to help resolve the issue but they don't seem to have any clue.

It almost looks like it happens when multiple requests happen simultaneously, it's like it doesn't handle it. The more load you put on the more frequent the error.

Our Server gets a good number of hits and at peak times you get this error more often than you get the actual page you're requesting.

(Though if you put the server in Production mode you can actually displays a different error which you can customise to tell the user to refresh to get past the problem)

I'm interested in bda's suggestion, I'm just not quite sure what he meant.