Bug #2054


Web server aborts page loading

Added by O'Neil Delpratt about 10 years ago. Updated almost 10 years ago.

Start date:
Due date:
% Done:


Estimated time:
Found in version:
Fixed in version:


This issue was reported by Petr Žák:

Relates to the close method. When I called close() method on processor's instance, it raise PHP warning : XSLT2 PHP close.

If I tried to create other new instance of SaxonProcessor after calling close processor on instance I used before(eg in cycle - see php attachment), webserver aborts page loading. As PHP programmer, I would except some PHP error, not strange abort of request without any message. If is required to use SaxonProcessor as singleton, so call only once initialization and only once close method, as PHP programmer I would except that this class is singleton by design - as singleton provided from PHP module.


xsltExamples.php (2.01 KB) xsltExamples.php O'Neil Delpratt, 2014-04-17 12:33
jet_err_6457.txt (47.3 KB) jet_err_6457.txt Jeroen Bobbeldijk, 2014-06-13 18:15
jet_err_6235.txt (47.3 KB) jet_err_6235.txt Jeroen Bobbeldijk, 2014-06-13 18:15
jet_err_3135.txt (47.6 KB) jet_err_3135.txt Jeroen Bobbeldijk, 2014-06-13 18:15
jet_err_2478.txt (48.8 KB) jet_err_2478.txt Jeroen Bobbeldijk, 2014-06-13 18:15
Actions #1

Updated by O'Neil Delpratt about 10 years ago

  • Subject changed from Wb server aborts page loading to Web server aborts page loading
Actions #2

Updated by O'Neil Delpratt about 10 years ago

php warning "XSLT2 PHP close" that is raised by calling close() method needs removing.

Advise from user:

About recreating instance, maybe you should write the processor class with private constructor and getInstance method() - as singleton design pattern, and private cleanup method that would be called in __destroy method(php magic method that is called when the object is unset, script is executed or memory is released)... Because many of PHP programmers create new instances in cycles and have many bad practices with coding.

Actions #3

Updated by Jeroen Bobbeldijk about 10 years ago

I get this quite often (like 1/3 of the page requests), it seems to be worse on v0.3-prerelease.

I have my processor in a singleton, and ->close it in a __destroy.

It also seems to be worse when I do more than 1 transform in a page request.

I'm getting jet_err_*.txt files in my webroot, but it doesn't contain a good error:

"JET RUNTIME HAS DETECTED UNRECOVERABLE ERROR: system exception at 0x0000000000000000"

Also, I think such errors should not break the site, a Java error should propagate to a PHP (fatal) error.

Actions #4

Updated by O'Neil Delpratt about 10 years ago

  • Status changed from New to In Progress

This is a problem which is on the priority list. I am also raising this issue with Excelsior Jet. Please may you send me the created jet_err_*.txt file.


Actions #5

Updated by Jeroen Bobbeldijk about 10 years ago

Sure, I attached four.

Are you sure this is in Jet? PHP CLI seems to work fine.

Actions #6

Updated by O'Neil Delpratt almost 10 years ago

  • Status changed from In Progress to Resolved

Thanks to the help of Jeroen Bobbeldijk for providing the solution to this bug issue, which we now mark as resolved.

Changea made:

  • Made jvm and env static

  • Made proper check on jvmCreated so we only launch 1 jvm

  • Made close function static

  • Removed Close function from php object, now calls close on SaxonProcessor from MSHUTDOWN

  • Made all references to env and jvm to SaxonProcessor::env and SaxonProcessor::jvm

The way it works now:

  • Create a jvm on the first new SaxonProcessor() for this php runtime (possibly within Apache)

  • Close the jvm on MSHUTDOWN (end of this specific php runtime, not request) .

This way the same jvm should be used over multiple requests, and the jvm should be stopped when the webserver/worker is stopped.

For background details of the problem see the article:

Actions #7

Updated by O'Neil Delpratt almost 10 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in version set to 0.3.1

Bug fixed in Saxon/C bete release 0.3.1

Please register to edit this issue

Also available in: Atom PDF