php-java-bridge-users Mailing List for PHP/Java Bridge

Hi Jost,

Really appreciate you taking time to write lengthy replies.

Another thing that I observed was I was using java_session(). In that case
the memory on the Tomcat server kept increasing with every hit on the page.
Because of that the tomcat server went out of memory very quickly.

I stopped using the java_session to verify that and found that memory didn't
go up that much. I have found a way to get my work done without using
java_session.

Do you know why using a java_session() could create such problem?

Thanks
-Ajit

-----Original Message-----
From: php...@li...
[mailto:php...@li...] 
Sent: Saturday, December 20, 2008 2:40 PM
To: php...@li...
Subject: Re: [Php-java-bridge-users] protocol error: ,Invalid document end
at col 16. Check the back end logforOutOfMemoryErrors

Hi Nathan,

I am afraid but this problem cannot be fixed on application level.

PHP/windows contains code to detect a broken connection, but it fails to
detect it if the back end has destroyed the channel w/o waiting for the
client. If the front end doesn't explicitly close the connection, the
connection goes back to the pool and PHP/windows returns it the next time
pfsockopen() is called. 

The PHP/Java Bridge back end destroys a channel only if it has to recover
from a java.lang.OutOfMemoryError. 

Unfortunately this means that the bridge cannot recover from an OutOfMemory
condition automatically, which is certainly not what we want.

PHP/Java Bridge version 5.4.1 contains code which explicitly destroys a
persistent connection if a protocol error occurred (it calls
"dieWithPersistentConnection(errorCode)" instead of simply "die(errorCode)")
>From the NEWS file:

Version 5.4.1

* If PHP is used within a J2EE server or servlet engine the option
  JAVA_PERSISTENT_SERVLET_CONNECTIONS is set. This means that the
  servlet option fcgi_children (see WEB-INF/web.xml) must be less than
  or equal to the servlet engine's thread pool size. It defaults to
  5. The smallest thread pool we've seen is the thread pool of the Sun
  J2EE server version 9, with 5 entries.

* If PHP is used within Apache or IIS via the java.so or
  php_java.dll the option JAVA_PERSISTENT_SERVLET_CONNECTIONS is
  set. This means that Apache/IIS "maxChilds" must be less than or
  equal to the servlet engine or J2EE server's "maxThreads" value,
  otherwise the additional PHP executables will hang. On Fedora and
  RedHat Linux we have verified that Tomcat's maxThreads == Apache
  maxChilds. If you're unsure, do not use the php_java.dll/java.so.

* If a windows Java back end is destroyed via the task manager, a
  PHP/windows front end keeps using the old persistent connections to
  the back end. If your Java back end requires a reboot (usually
  because new software has been installed), reboot the entire windows
  machine to avoid problems with old resources. Or use a unix machine
  as the HTTP server front end instead.

* All options can now be set on the command line. Example:

    php-cgi -djava.persistent_servlet_connections=On test.php



However, the fundamental problem, that PHP cannot detect broken connections
on windows, still exists. Please report this problem to the PHP maintainers.


Regards,
Jost Bökemeier



      

----------------------------------------------------------------------------
--
_______________________________________________
php-java-bridge-users mailing list
php...@li...
https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users

Hi Nathan,

I am afraid but this problem cannot be fixed on application level.

PHP/windows contains code to detect a broken connection, but it fails to detect it if the back end has destroyed the channel w/o waiting for the client. If the front end doesn't explicitly close the connection, the connection goes back to the pool and PHP/windows returns it the next time pfsockopen() is called. 

The PHP/Java Bridge back end destroys a channel only if it has to recover from a java.lang.OutOfMemoryError. 

Unfortunately this means that the bridge cannot recover from an OutOfMemory condition automatically, which is certainly not what we want.

PHP/Java Bridge version 5.4.1 contains code which explicitly destroys a persistent connection if a protocol error occurred (it calls "dieWithPersistentConnection(errorCode)" instead of simply "die(errorCode)") From the NEWS file:

Version 5.4.1

* If PHP is used within a J2EE server or servlet engine the option
  JAVA_PERSISTENT_SERVLET_CONNECTIONS is set. This means that the
  servlet option fcgi_children (see WEB-INF/web.xml) must be less than
  or equal to the servlet engine's thread pool size. It defaults to
  5. The smallest thread pool we've seen is the thread pool of the Sun
  J2EE server version 9, with 5 entries.

* If PHP is used within Apache or IIS via the java.so or
  php_java.dll the option JAVA_PERSISTENT_SERVLET_CONNECTIONS is
  set. This means that Apache/IIS "maxChilds" must be less than or
  equal to the servlet engine or J2EE server's "maxThreads" value,
  otherwise the additional PHP executables will hang. On Fedora and
  RedHat Linux we have verified that Tomcat's maxThreads == Apache
  maxChilds. If you're unsure, do not use the php_java.dll/java.so.

* If a windows Java back end is destroyed via the task manager, a
  PHP/windows front end keeps using the old persistent connections to
  the back end. If your Java back end requires a reboot (usually
  because new software has been installed), reboot the entire windows
  machine to avoid problems with old resources. Or use a unix machine
  as the HTTP server front end instead.

* All options can now be set on the command line. Example:

    php-cgi -djava.persistent_servlet_connections=On test.php



However, the fundamental problem, that PHP cannot detect broken connections on windows, still exists. Please report this problem to the PHP maintainers.


Regards,
Jost Bökemeier