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

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