Menu
▾
▴
php-java-bridge-users
|
From: <php...@li...> - 2010-02-14 14:37:51
|
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? |
|
From: <php...@li...> - 2010-02-14 17:52:38
|
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
|
|
From: <php...@li...> - 2010-02-14 18:28:59
|
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? |
|
From: <php...@li...> - 2010-02-14 20:54:09
|
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.
|
|
From: <php...@li...> - 2010-02-15 04:44:04
|
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
|
|
From: <php...@li...> - 2010-02-19 05:51:30
|
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
|
|
From: <php...@li...> - 2010-03-08 16:15:39
|
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 > |
|
From: <php...@li...> - 2010-03-08 17:02:27
|
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® 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
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X