php-java-bridge-users Mailing List for PHP/Java Bridge (Page 69)

Hello!

Thanks for your reply and your explanation of the problem. We are looking forward to 5.3.3 :-)


> java(...)
> // workaround for a 5.3.2 bug which must execute the second java statement within 30 seconds
> java(...)
> wait(...)
> java(...)

> However, I am curious why the wait() for more than 30 seconds is necessary?

I can think of two possible explanations in our current setup.

Firstly, we are making use of the JavaBridge in a backend daemon PHP script which runs indefinitely polling a message queue at regular intervals. Handling a message usually involves making one or more java()-calls. The interval between java()-calls is therefore dependent on the message frequency. Using PHP for this kind of backend business logic is of course a rather bad idea, but having to work with an existing architecture, we don't really have an option.
Maybe this issue could be resolved on the user level by flushing the JavaBridge somehow before the daemon goes back to sleep waiting for its next message?

Secondly, the external Java API which we are calling using the JavaBridge is at times very, very slow (response times of up to several minutes). For example:

function getExternalObjectName($externalObjectId)
{
    $externalObject = java('...')->getObject($externalObjectId);
    // the script stalls for one minute waiting for the above call to finish
    return java_values($externalObject->getName());
}


Best regards,
Johannes Staffans
itCampus GmbH

Hi,

to fix this problem please add the following line to your Java.inc (or Protocol.inc):

  $this->protocol->handler = $this->protocol->socketHandler;
+ $this->protocol->flush(); // don't wait for the next statement
  }

This fix will be in PHP/Java Bridge version 5.3.3.


Regards,
Jost Boekemeier




      

Hi,

please see my other mail which explains the problem.


Until version 5.3.3 is released please add a java() dummy statement to your script:

java(...)
// workaround for a 5.3.2 bug which must execute the second java statement within 30 seconds
java(...) 
wait(...)
java(...)
...


However, I am curious why the wait() for more than 30 seconds is necessary?


Regards,
Jost Boekemeier



      

Hi,

thank you very much for the bug report.


Your script contains the following code:

java(...)
wait(more than 30sec)
java(...)

Since the bridge avoids write/write/read to accommodate BSD's socket implementation, it has no chance to do a context switch before the ContextFactory times out after 30 seconds, checked every 10 minutes.

Hence the spurious protocol error and the exceptions.

Since John Nagle has fixed this TCP problem and all operating systems (except *BSD and probably OSX) seem to contain this fix, I will revert this change. The delayed ack will make the bridge slower on *BSD and OSX (~500ms per request), but I don't see a way to fix this on app level without introducing another network round-trip, which will make the bridge slower on *all* operating systems.[3]

The change will be in PHP/Java Bridge version 5.3.3, which will be released this week.

Again, thank you very much for reporting this problem!


Regards,
Jost Boekemeier

[1] A program demonstrating this problem:
http://lists.freebsd.org/pipermail/freebsd-bugs/2006-April/018144.html

[2] John Nagle's explanation: http://developers.slashdot.org/comments.pl?sid=174457&cid=14515105 and http://freebsd.monkey.org/freebsd-net/200601/msg00156.html

[3] As far as I know osx and bsd don't have a modern java environment, anyway. Users who want to run the bridge on these os may as well use unix domain sockets instead, see the README for details.



      

Hello!

> the web app path is missing after the @,  so I assume you use the JavaBridge.jar in development mode.

If by "development mode" you mean running the JavaBridge.jar as standalone, then yes:

java -jar JavaBridge.jar SERVLET_LOCAL:8080 4 /var/log/javabridge.log

> Furthermore I assume you're running windows or you have switched of the PipeContextServer.

The JavaBridge is running on Ubuntu 8.04. What the PipeContextServer is, I do not know. Our logs contain no reference to it.

> This is either a serious bug in the JavaBridge.jar or,
> more likely, you have mixed an old version of the front-end with a recent version of the back-end or vice versa.

I considered this as well. In reality, we are currently including the Java.inc file over http:

require_once("http://localhost:8080/JavaBridge/java/Java.inc");

Which I would think ensures that the frontend is indeed of the same version as the backend.

Regards,
Johannes Staffans
itCampus GmbH

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
php-java-bridge-users mailing list
php...@li...
https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users

>> Your client may not be interested in the result anymore... :)

Very possible.  But with asynchronous requests (AJAX) the client could 
continue working while waiting on the result.  I've never seen a request 
take longer than a couple of seconds, but everything we are doing here is 
on an Intranet.  I was just curious about issues that might arise in other 
circumstances.  Thanks for the information.  Very informative.

Charles Shaffer
Senior Analyst
NTN-Bower Corporation

Hi,


> java.io.IOException: No context available for: 21@.

the web app path is missing after the @,  so I assume you use the JavaBridge.jar in development mode. Furthermore I assume you're running windows or you have switched of the PipeContextServer.

In any case PHP sends an initial PUT request to the back end and then switches to a ContextRunner, keeping a persistent connection to it until it dies.

When the persistent connection is terminated, the client must not refer to its destroyed context anymore.

This is either a serious bug in the JavaBridge.jar or, more likely, you have mixed an old version of the front-end with a recent version of the back-end or vice versa. 


Regards,
Jost Boekemeier





      

Hi,

> If I am following what you are saying, then if I run a
> query that takes 
> longer than 30 seconds on the backend database server, the
> PHP process on 
> the server will die before the result set is returned.  

The result set is returned and php will process further statements until the maximum execution time set in your php.ini file is reached. wait() states do not count as execution time.


> If so, when is the allocated memory reclaimed?  

The reference counter reclaims unused memory immediately, i.e. __destruct() is called even before the next statement is executed. Cycles will be reclaimed when the script terminates.


> problem if I ever run a query that takes longer than 30

Your client may not be interested in the result anymore... :)


Regards,
Jost Boekemeier



      

Hi,

please see the test/cli.java from the documentation server folder.


Regards,
Jost Boekemeier



      

Hello!

Using the standalone version of the JavaBridge v5.3.2.1.2, we are getting this error, seemingly when the JavaBridge is called upon after a period of extended inactivity:

Nov 11 12:42:41 VMBridge ERROR: An exception occured: java.io.IOException: No context available for: 21@.
java.io.IOException: No context available for: 21@.
        at php.java.bridge.http.ContextRunner.init(ContextRunner.java:120)
        at php.java.bridge.http.ContextRunner.run(ContextRunner.java:139)
        at php.java.bridge.ThreadPool$Delegate.run(ThreadPool.java:60)
Nov 11 12:42:41 VMBridge DEBUG: end (thread returned to pool): Thread[JavaBridgeContextRunner#6,5,JavaBridgeContextRunner#6]

Any ideas?

Regards,

Johannes Staffans
itCampus GmbH

Just a quick update on this issue:

>> seemingly random, frequent intervals greeted by a friendly
>> "Protocol error; , Invalid document end at col 10.
>> Check the back end log for details."

> Can you please open a ticket (please use http://sourceforge.net/tracker/?func=add&group_id=117793&atid=679233),
> set the log level to 4 or above and attach the log at the end of the ticket?

> Please start tomcat with the option -Dphp.java.bridge.default_log_level=4

> JAVA_OPTS=-Dphp.java.bridge.default_log_level=4 /opt/tomcat/catalina.sh run

We are currently doing this, but in the last several days, the error has not reappeared. Maybe setting log_level to 4 fixes it :-)
I will return to this issue when we have more information. For the time being, we are getting another error for which I am opening a new thread.

Best regards,

Johannes Staffans
itCampus GmbH

Hi,

A PHP script cannot run for more than 30 seconds. However, this isn't a
> problem because all relevant information is stored in the Java backend. For
> example:
>


> jrunscript -classpath JavaBridge.jar -l php-interactive
> php-interactive> $vec = new java("java.lang.Vector"); $vec->add(1);
> php-interactive> echo $vec
> [1]
> php-interactive> die();
> ScriptError: Request$AbortException
> php-interactive> echo $vec
> [1]
>
> The above example shows that, even though the PHP continuation has been
> restarted, the script state isn't lost.


Could you provide me with a Java code example for this. I have already at
startup

(note: globally declared manager, engine, and invocable)
manager = new javax.script.ScriptEngineManager();
e = manager.getEngineByName("php-invocable");

// read php script
java.io.File sourceFile = new java.io.File(mycode.php);
java.io.FileReader fr = new java.io.FileReader(sourceFile);
e.eval(fr);
i = (javax.script.Invocable) e;

>From what you said I gather that after 30 seconds 'i' can no longer be used.
What java code do i put then to restart the PHP continuation with the
preserved state?

Thanks,
Bart



> Regards,
> Jost Boekemeier
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> php-java-bridge-users mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users
>



-- 
The new is always the old. Everything that's old was once new, and
everything that's new will one day be old. The oldest thing of all is the
present, because there's never been anything else but the present. No one
has ever lived in the past, and no one lives in the future, either.

Jost,

I am using the bridge to execute queries on a backend database from PHP. 
If I am following what you are saying, then if I run a query that takes 
longer than 30 seconds on the backend database server, the PHP process on 
the server will die before the result set is returned.  But it doesn't 
matter because when the bridge returns the result set, the PHP process 
will restart and remember it's state?

If so, when is the allocated memory reclaimed?  If not, will I have a 
problem if I ever run a query that takes longer than 30 seconds?

>> jrunscript -classpath JavaBridge.jar -l php-interactive
>> php-interactive> $vec = new java("java.lang.Vector"); $vec->add(1);
>> php-interactive> echo $vec
>> [1]
>> php-interactive> die();
>> ScriptError: Request$AbortException
>> php-interactive> echo $vec
>> [1]

>> The above example shows that, even though the PHP continuation has been 
restarted, the script state isn't lost.

Charles Shaffer
Senior Analyst
NTN-Bower Corporation

Hi,

PHP is a scripting language designed for web applications. It isn't really usable outside of the web environment. 

It uses reference counting. It can reclaim objects immediately but fails to detect cycles, something which is very useful for web applications. But its missing garbage collector is problematic in a standalone environment.

All PHP libraries have been written with this "restriction" in mind; in fact the "no state" paradigm isn't really a restriction, it is a key feature of PHP. 


> php.java.bridge.Request$AbortException

This is a so-called "one-shot continuation", implemented as a special Java exception. It is called when the PHP script has terminated, either explicitly or by its timer.


> What could be the cause of this error? 

That's PHP's normal behaviour. If you increase its timeout you will run into the next timeout from the HTTP server. And even if you increase the HTTP server's timeout, the client browser (IE, Firefox) will disconnect after ~30 seconds.


> I am initializing the scripting engine and invocable only
> once, when starting my program. 

A PHP script cannot run for more than 30 seconds. However, this isn't a problem because all relevant information is stored in the Java backend. For example:


jrunscript -classpath JavaBridge.jar -l php-interactive
php-interactive> $vec = new java("java.lang.Vector"); $vec->add(1);
php-interactive> echo $vec
[1]
php-interactive> die();
ScriptError: Request$AbortException
php-interactive> echo $vec
[1]

The above example shows that, even though the PHP continuation has been restarted, the script state isn't lost.


Regards,
Jost Boekemeier



      

Hi,

I was hoping someone could help me with the following:

I'm calling php code on php objects from java using java_closure to create
the dynamic proxies. Most of the time things work smoothly, but from time to
time I get the following error:

php.java.bridge.Request$AbortException
        at php.java.bridge.Request.handleSubRequests(Request.java:611)
        at php.java.bridge.PhpProcedure.invoke(PhpProcedure.java:82)
        at php.java.bridge.PhpProcedure.invoke(PhpProcedure.java:106)
Maximum execution time of 60 seconds exceeded in <b>
http://127.0.0.1:9267/JavaBridge/java/Java.inc</b> on line <b>841</b><br />

What could be the cause of this error? It occurs when I for example do the
following:

call invokeMethod on a proxy object
wait for a while (assumingly passed the maximum execution time)
call invokeMethod again

I am initializing the scripting engine and invocable only once, when
starting my program. Does the invocable need to be refreshed in between or
something like that? I can increase the execution time in php.ini, but since
my program is user driven and the user can decide to wait long periods
before doing something (leading to an invokeMethod call), this would not
really be a nice solution.

Thanks for any help,
Bart

Hi,

the PHP/Java Bridge version 5.3.3 is available for testing:

=>   http://downloads.sourceforge.net/php-java-bridge/php-java-bridge_5.3.3_j2ee.zip?use_mirror=

PHP/Java Bridge version 5.3.3 will be last regular release.


Regards,
Jost Boekemeier





      

Hi,

> seemingly random, frequent intervals greeted by a friendly
> "Protocol error; , Invalid document end at col 10.
> Check the back end log for details."

Can you please open a ticket (please use http://sourceforge.net/tracker/?func=add&group_id=117793&atid=679233), set the log level to 4 or above and attach the log at the end of the ticket?

Please start tomcat with the option -Dphp.java.bridge.default_log_level=4

JAVA_OPTS=-Dphp.java.bridge.default_log_level=4 /opt/tomcat/catalina.sh run


> Sadly, I do not know where to find the back end log.

Unless you have log4j ("chainsaw") running, errors appear in the tomcat log file. Look for OutOfMemoryErrors or something.
 

> The problem seems to be related to the error described in
> this previous thread:

No. The protocol error mentioned there was caused by "GNU Java", a buggy "Java" implementation which was popular until Sun has released Java as open source.


> The problem is there in both cases. In addition, even
> though the log file is specified explicitly in the
> standalone case, there are no error messages to be had
> there..

Well, over a year ago I have committed a change which suppresses all exceptions on default_log_level <= 3. Since the bridge code was mature I didn't think this may become an issue. 

However, the trace is still useful when a broken Java implementation is used or the back end reflects bugs in PHP itself (see http://bugs.php.net/bug.php?id=46451, which translates into a NullPointerException in the back end and a connection abort).  


> Any clues about how to resolve this problem? 

The communication failure can be caused by System.exit() as well as by a OutOfMemoryError. The details will be in the log file; we'll see. 


Regards,
Jost Boekemeier



      

Hello!

We are running an Ubuntu 8.04 server with a backend daemon program written in PHP that uses the PHP-Java-Bridge v5.3.2.1.2 for communicating with an external Java API. When we attempt to call up the PHP-Java-Bridge, we are at seemingly random, frequent intervals greeted by a friendly die() coming from line 784 in the Java.inc-file. The error message is:

"Protocol error; , Invalid document end at col 10. Check the back end log for details."

Sadly, I do not know where to find the back end log.

The problem seems to be related to the error described in this previous thread:

http://sourceforge.net/mailarchive/forum.php?thread_name=48B6FC13.4030406%40federatedmedia.net&forum_name=php-java-bridge-users

Like in the above thread, the error seems to spring up merely by doing

require_once("http://localhost:8080/JavaBridge/java/Java.inc");

.. which we do in a single place only when we need to communicate with the external Java API. Since in our case, the program calling JavaBridge functions is a single-threaded backend program, I do not believe that the problem of running out of threads should be an issue.

We have tried running the JavaBridge both as a Tomcat web app (using Tomcat 6.x and
Java/Sun 1.5.0_15) and as standalone:

java -jar JavaBridge.jar SERVLET_LOCAL:8080 3 /var/log/javabridge.log

The problem is there in both cases. In addition, even though the log file is specified explicitly in the standalone case, there are no error messages to be had there..

Any clues about how to resolve this problem? At the moment, our whole backend is crashing quite resolutely due to this issue.

Best regards,
Johannes Staffans
itCampus GmbH

php...@li... a écrit :
>> disable the 
>> TOMCAT5_SECURITY in /etc/default/tomcat5,
> 
> Not really. See FAQ http://php-java-bridge.sourceforge.net/pjb/FAQ.html#tomcat-security. :)

You're right, it is not needed. A complete production should not disable 
tomcat security.

I had some more troubleshooting to do and didn't want to use some time 
on tomcat security configuration, as i was already trying to figure how 
to install some four technos, all of which were totally new for me :-)

Hi,

PHP must be installed (and enabled) in order to run PHP scripts within Apache or IIS, I think. 





      

> disable the 
> TOMCAT5_SECURITY in /etc/default/tomcat5,

Not really. See FAQ http://php-java-bridge.sourceforge.net/pjb/FAQ.html#tomcat-security. :)







      

Apologies in advance if this goes out more than once....

 

I have the php/java bridge working in tomcat and a symlink to the Apache
document root .  Going straight to tomcat everything works but going to
Apache (http://127.0.0.1/JavaBride or http://127.0.0.1/JavaBridge/index.php
) the browser tries to download the file, either the phtml of the php.  

 

TIA, Jeff

 

David Pradier a écrit :
> Thanks Jost,
> i'm currently trying to use tomcat, as there are more tutorials. I'll 
> come back to the list when I've succeeded, if only to point my errors.

Hi,

I've finally managed to have a working debian etch PhpJavaBridge tomcat 
jasperreports install :-)
For the record, here are some things i needed to do :

- to enable the servlet : it is necessary to configure or disable the 
TOMCAT5_SECURITY in /etc/default/tomcat5,

- to access the servlet : the tomcat port on debian is 8180, not 8080,

- to include the Java.inc file coming from the servlet : put 
"allow_url_include = On" in /etc/php5/apache2/php.ini,

- to have the PhpJavaBridge tests working : put "define("JAVA_HOSTS", 
"127.0.0.1:8180");" instead of "define("JAVA_HOSTS", "127.0.0.1:8080");" 
in /var/lib/tomcat5/webapps/JavaBridge/java/Java.inc

- to load all my java libraries at the same time : put all my 
/usr/share/java/*.jar and generally each and every .jar i use in 
/var/lib/tomcat5/webapps/JavaBridge/WEB-INF/lib/

I hope this helps somebody.

Regards,
David

php...@li... a écrit :
> Hi,
>> But i AM using a single java_require() call loading all my
>> libraries !
> More importantly each class and all dependencies must be loaded by exactly one class loader. I have updated the FAQ entry, please see:
> http://php-java-bridge.sf.net/pjb/FAQ.html#java-dll-hell
>> (I have even tested with a single .jar file containing
>> everything to be sure...)
> As long as the depedency is missing or loaded from another loader, you will get this error -- or even a ClassCastException, because the same class loaded via two different loaders creates two assignment-incompatible class instances. 
> Regards,
> Jost Boekemeier

Thanks Jost,

i'm currently trying to use tomcat, as there are more tutorials. I'll 
come back to the list when I've succeeded, if only to point my errors.

David

Hi,

> But i AM using a single java_require() call loading all my
> libraries !

More importantly each class and all dependencies must be loaded by exactly one class loader. I have updated the FAQ entry, please see:

http://php-java-bridge.sf.net/pjb/FAQ.html#java-dll-hell


> (I have even tested with a single .jar file containing
> everything to be sure...)

As long as the depedency is missing or loaded from another loader, you will get this error -- or even a ClassCastException, because the same class loaded via two different loaders creates two assignment-incompatible class instances. 


Regards,
Jost Boekemeier