Unexpected error: Cannot load document [in XSLT]

[alazzaro]

While using the document() function (in XSLT) to load an additional XML document, I've encountered the following sporadic error message:

The resource [i]http://...[/i] could not be loaded because of an unexpected error (MCS-604)

I'm not sure why this seems to occur. Sometimes, the XML document loads fine. Sometimes, I get the above error message.

Any clues on what could be causing this error message? Could it be tomcat and not FMS?

I'm using FMS 7 Advanced on Mac OS 10.4.

Thanks for the help,

Adrien

[Martin Brändle]

I use the document() function intensively in one of our pages and get the same problems (with FMS7A 7v3 on OS X 10.3.9 server).

I could reduce them by tweaking some Tomcat parameters (see this thread for some hints), but they are still not eliminated and appear sporadically.

Maybe we should report this as a bug to FMI? Anyway, the WPE is slow as well if it has to generate a large XML result set tree. This one I already told FMI.

[alazzaro]

I have already looked at that thread and followed your advice for the tomcat settings. Nevertheless, changing them did not solve the problem. As with the person in the thread, my log files only show 200 error codes (and not 500 error codes). I've reported the issue (over the phone) to a Filemaker representative and haven't yet gotten a response. Maybe you should also contact him (via email) and let him know that this is not an isolated incident. What do you think? Just let me know and I can give you his email.

In the meantime, how many XML documents are you loading with your XSLT sheet? I merely have a FMPLAYOUT query (for valuelists) and another fmresulset query. FMS7A should be able to handle the traffic load... no apparent reason for it to return an error message (since the query gets queued)...

[Martin Brändle]

Up to 100 times in the corresponding page. I could also use portals, but then the page loads much too slow, i.e. it loads when the whole XML result tree has been produced, and then the user has to wait >10-20 seconds until he sees something. I made some timings with process monitor. The slow behavior is not a problem of the database, but solely of the WPE engine that produces the XML. The XML parsing and XSLT transformation by Xerces/Xalan again is fast. By using document(), I can split the XML tree into small chunks that are processed immediately, and the user sees at least that something happens and that the page is building up. If the WPE were faster, I would switch back to the portal solution.

Please provide the E-mail back forum (I can contact your rep and one in Germany). If you are interested to see the behaviour of my solution, I can give a demo account.

[alazzaro]

In my solution, I merely load two additional documents and it still gives me the error messages. If you don't mind, having a demo account to your solution would probably be helpful.

For the rep, I talked to Chuck Melton [[email protected]] at Filemaker. He isn't very knowledgeable about XSLT but can pass along any concerns (and code samples) to a group of engineers. I can also contact the rep in Germany.

In the meantime, I had one additional, possibly dumb question. Every XML document requested needs to have an associate namespace, correct? Can I have several documents with the same namespace but with different prefixes? (I am fairly new to XSLT and XML)

For example:

‹xsl:stylesheet exclude-result-prefixes="xsl fmxslt fmrs fmq date week slots of" version="1.0"

   xmlns:fmq="http://www.filemaker.com/xml/query"

   xmlns:fmrs="http://www.filemaker.com/xml/fmresultset"

   xmlns:fmxslt="xalan://com.fmi.xslt.ExtensionFunctions"

   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

   xmlns:date="http://exslt.org/dates-and-times"

   xmlns:week="http://www.filemaker.com/xml/fmresultset"

   xmlns:slots="http://www.filemaker.com/xml/fmresultset"

   xmlns:of="http://www.filemaker.com/xml/fmresultset"›

Since I load 3 documents (using the fmresultset grammar, hence 3 fmresultset namespaces) into 3 variables:

‹xsl:variable name="week" select="document($uri_query1)/week:fmresultset/week:resultset"/›

‹xsl:variable name="timeslots" select="document($uri_query2)/slots:fmresultset/slots:resultset"/›

‹xsl:variable name="officehours" select="document($uri_query3)/of:fmresultset/of:resultset"/›

Is this the right way to do it? Doing it this way seems to confuse the processor when you have several embedded for-each loops accross different XML documents.

Thanks for the help,

Adrien

[Martin Brändle]

Every XML document requested needs to have an associate namespace, correct? Can I have several documents with the same namespace but with different prefixes?

You don't need to define a new prefix for each document() function, i.e. the fmrs prefix is already sufficient. I assume that the problems you have are a problem of the XSLT implementation (Xalan) used in FMS7A, but in principle your code should work.

I sometimes load XML documents with a different schema than the fmresultset grammar, without declaring any namespace and prefix for them. Works also; probably a default namespace is the attributed this XML tree.

I looked up Michael Kay's comments in his famous XSLT Programmer's reference (a book every XSLT programmer should have) on namespaces, but did not find anything that would contradict your code example. The main points are the following:

- a namespace declaration must be globally unique (unique across all documents of the planet)

- "the scope of the namespace declaration is the element on which it appears and all its children and descendants, excluding any subtree where the same prefix is associated with a different URI".

- For XPaths: "In some situations (for example, if your document uses more than one prefix to refer to the same namespace URI) the system might not use the original prefix, but another prefix that identifies the same namespace URI." IMO, here might be the problem with Xalan. "In a few cases, typically where the source document uses the same prefix to refer to more than one namespace, it may be necessary for the processor to invent an arbitrary prefix".

If you want to check what happens in your code, you can display the three components of an element with the name(), local-name(), and namespace-uri() functions.

[beverly]

Remember that you are "loading" the XML into a variable when you use document(). Since you are specifying that variable and any path to elements, you don't need the namespace when you 'call' any of the elements.

[alazzaro]

Thanks for the insight.

BTW, I was able to resolve the previously mentionend errors: I separated the Publishing Engine (and Web server) from the FM server (they were previously installed on the same machine). I no longer experience those 'Cannot load' errors!

Martin, are all your components (web server, publishing engine and FM server) on the same machine? Did you try them on separate machines to see if you still get those errors?

[Martin Brändle]

Yes, we have two servers: one is the database server, the other the WPE/web server. Both connected by a 1 Gbit/s cross cable.

[Martin Brändle]

I found this on the Xalan-J 2.6 website There might be java.lang.OutOfMemoryErrors if multiple documents are loaded with document() . These are cached normally, and the cache might run out. The caching can be turned off by placing a <?xalan-doc-cache-off?> processing instruction after document().

[Martin Brändle]

Xalan-J is even version 2.4. Look at the attachment and try it out on your server. Call it with http://yourhost/fmi/xsl/test_xalan.xsl .

test_xalan.zip

[Martin Brändle]

A complete de- and reinstall of the WPE (with all updaters) on our webserver did not help: We still have the same annoying 500 (MCS-603) errors with XSLT document().

According to the logs in /Library/FileMaker Server 7/Web Publishing/jakarta-tomcat/logs these seem to be timeout problems with the Tomcat JK connector, and the Java throws exceptions.

Java version is 1.4.2_05

I've sent in a bug report to FMI.