Thread: [Php-java-bridge-users] Jetty 15 Second delay (15000 ms), Tomcat OK

I am using the JavaBridge template war for version 5.5.4.1 on Jetty. I
am using PHP on a separate IIS server. Running test.php on IIS with
the Java.inc from the Jetty server has this behavior Jetty. The
request begins, exactly 15 seconds pass, and then the request
completes showing all the Java System properties. So, it works, but
only after exactly 15000 ms.

On Tomcat the same arrangement completes the request instantly. I have
tried various settings in the 'define' section of Java.inc. I have
tried to properly set promiscuous mode in the web.xml file.

The only other clue is that if I test with a telnet PUT the console
output of Jetty says:

2010-02-14 06:36:43.029:INFO:/JavaBridge:handleHttpConnection init failed

Any idea what I should do to diagnose the problem with Jetty?

Hi,

PHP/Java Bridge version >= 5.5.4 uses HTTP/1.1 chunked connections to
communicate with the servlet. From the NEWS file:
-----

* If the Java environment doesn't allow java.lang.Threads, Sockets, or
  if the back end doesn't run on localhost
  ("127.0.0.1".equals(req.getRemoteAddr()), or if the promiscuous
  option is set, the bridge now uses a HTTP tunnel to communicate with
  the back end.  Example:

  --
  telnet YOURHOST.com 8080 
PUT /JavaBridge/foo.phpjavabridge HTTP/1.1
Host: YOURHOST.com:8080
Transfer-Encoding: chunked

22
<H p="1" v="java.lang.String"></H>
b
<F p="E" />
0

-----

We have tested this with Oracle/Bea WebLogic, Sun Application server,
Glassfish, Tomcat.

Servlet engines which do not flush their output immediately cannot use
chunked encoding to implement a two-way connection.

PHP/Java Bridge version 5.5.4 still contains  "ContextRunners" which
will be used if(LOCAL_ADDR.equals(req.getRemoteAddr()) && contextServer!
=null && contextServer.isAvailable(channel)). If you install jetty on
the local host and do not switch off the SocketContextServer, the bridge
will still work with Jetty.


> tried to properly set promiscuous mode

If you switch off promiscuous mode again and run jetty on localhost (ip:
127.0.0.1), it should work.


But I am currently preparing PHP/Java Bridge version 6.0.0, which will
not contain these ContextServers anymore; chunked connections will be
the only way to communicate with the servlet.

I will try to find a workaround. In the worst case we'll have flag Jetty
as unsupported.

Which Jetty version and which operating system version do you use?



Regards,
Jost Bökemeier

Thanks for explaining the other options. I'll try it out. I am using
Jetty 7.0.1 on Windows Server 2003 with IIS.

Thanks,

McKinley

On Sun, Feb 14, 2010 at 5:49 PM,
<php...@li...> wrote:

> We have tested this with Oracle/Bea WebLogic, Sun Application server,
> Glassfish, Tomcat.
>
> Servlet engines which do not flush their output immediately cannot use
> chunked encoding to implement a two-way connection.
>
> PHP/Java Bridge version 5.5.4 still contains  "ContextRunners" which
> will be used if(LOCAL_ADDR.equals(req.getRemoteAddr()) && contextServer!
> =null && contextServer.isAvailable(channel)). If you install jetty on
> the local host and do not switch off the SocketContextServer, the bridge
> will still work with Jetty.
>
> Which Jetty version and which operating system version do you use?

Jetty still seems to not work without the 15 second delay. Promiscuous
is off and based on the Jetty output below I am sure that I am bound
to 127.0.0.1. In Java.inc I a have define ("JAVA_HOSTS",
"127.0.0.1:8080");

2010-02-14 12:35:32.466:INFO::Started SelectChannelConnector@127.0.0.1:8080
2010-02-14 12:35:46.904:INFO:/JavaBridge:PhpJavaServlet: PHP/Java
Bridge servlet D:\Programs\jetty-hightide-7.0.1.v20091125\webapps\JavaBridge
version 5.5.4.1 ready.

Do I need anything in the web.xml or properties to specifically enable
SocketContextServer?

Thanks,

McKinley

On Sun, Feb 14, 2010 at 5:49 PM,
<php...@li...> wrote:
> PHP/Java Bridge version 5.5.4 still contains  "ContextRunners" which
> will be used if(LOCAL_ADDR.equals(req.getRemoteAddr()) && contextServer!
> If you install jetty on
> the local host and do not switch off the SocketContextServer, the bridge
> will still work with Jetty.
>
> If you switch off promiscuous mode again and run jetty on localhost (ip:
> 127.0.0.1), it should work.

On Sun, 2010-02-14 at 20:54 +0000,
php...@li... wrote:
> etty still seems to not work without the 15 second delay

I have tested the bridge on jetty-6.1.20. It runs the bridge without any
problems.


Looking at the code I see this:

	sout.writeTo(resOut);
	    if(bridge.logLevel>3) bridge.logDebug("redirecting to port# "+
channelName);
	    sin.close();
	    try {res.flushBuffer(); } catch (Throwable t)
{Util.printStackTrace(t);} // resin ignores resOut.close()
	    try {resOut.close(); } catch (Throwable t)
{Util.printStackTrace(t);} // Sun Java System AS 9 ignores flushBuffer()
	    this.waitForContext(ctx);

If Jetty version 7 ignores both, res.flushBuffer() and resOut.close(),
the front-end won't receive the data before the timeout.

This may be a Jetty 7 bug.


I will test Jetty 7, if I have some time.


Regards,
Jost Bökemeier

This is indeed a Jetty 7 bug. Jetty doesn't flush the output buffer
"res.flushBuffer()" for HTTP/1.0 connections, so the code runs into a
wait timeout. I won't change the bridge code to work around this bug.
But Jetty 7.0  supports HTTP/1.1 chunked connections:

Please add 

<context-param>
           <param-name>promiscuous</param-name>
           <param-value>true</param-value>
</context-param>

after the </listener> declration of your WEB-INF/web.xml to work around
this Jetty 7 bug.


Regards,
Jost Bökemeier

I filled a bug with Eclipse and I was asked:

"Greg Wilkins 2010-03-05 02:27:12 EST
Can you give a bit more information about the request that is not being
flushed.

Does the response have Connection:keep-alive set and a Content-Length?"

Do you know the answer? I'll update the bug report.

Thanks,

McKinley

On Fri, Feb 19, 2010 at 5:52 AM,
<php...@li...> wrote:
> This is indeed a Jetty 7 bug. Jetty doesn't flush the output buffer
> "res.flushBuffer()" for HTTP/1.0 connections, so the code runs into a
> wait timeout. I won't change the bridge code to work around this bug.
> But Jetty 7.0  supports HTTP/1.1 chunked connections:
>
> Please add
>
> <context-param>
>           <param-name>promiscuous</param-name>
>           <param-value>true</param-value>
> </context-param>
>
> after the </listener> declration of your WEB-INF/web.xml to work around
> this Jetty 7 bug.
>
>
> Regards,
> Jost Bökemeier
>

The problem is that jetty doesn't flush the response buffer. In pseudo code:

protected void doPut (HttpServletRequest req, HttpServletResponse res) {

   res.getOutputStream().write(1);
   res.setContentLength(1);

   try {res.flushBuffer(); } catch (Exception t) {t.printStackTrace(); }
   try {resOut.close(); } catch (Exception t) {t.printStackTrace(t);}
   // response must be flushed right here, not at the end of the
service() routine

   Thread.wait(15000);

 }


> Connection:keep-alive

It's a HTTP/1.0 request. If jetty sets keep-alive for a HTTP/1.0
request, we've found another bug, I think.


BTW: Jetty contains another serious bug:

  requestDispatcher.include(req, res);

If req is an instance of HttpServletRequestWrapper, jetty tries to
find the original request in the thread context. This fails if the
current thread is not a servlet thread. You can verify this bug by
clicking on the jsr223.jsp example of the JavaBridge.war; jetty
crashes with a NullPointerException.


Regards,
Jost Bökemeier



On 3/8/10, php...@li...
<php...@li...> wrote:
> I filled a bug with Eclipse and I was asked:
>
> "Greg Wilkins 2010-03-05 02:27:12 EST
> Can you give a bit more information about the request that is not being
> flushed.
>
> Does the response have Connection:keep-alive set and a Content-Length?"
>
> Do you know the answer? I'll update the bug report.
>
> Thanks,
>
> McKinley
>
> On Fri, Feb 19, 2010 at 5:52 AM,
> <php...@li...> wrote:
>> This is indeed a Jetty 7 bug. Jetty doesn't flush the output buffer
>> "res.flushBuffer()" for HTTP/1.0 connections, so the code runs into a
>> wait timeout. I won't change the bridge code to work around this bug.
>> But Jetty 7.0  supports HTTP/1.1 chunked connections:
>>
>> Please add
>>
>> <context-param>
>>           <param-name>promiscuous</param-name>
>>           <param-value>true</param-value>
>> </context-param>
>>
>> after the </listener> declration of your WEB-INF/web.xml to work around
>> this Jetty 7 bug.
>>
>>
>> Regards,
>> Jost Bökemeier
>>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> php-java-bridge-users mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users
>