From: <php...@li...> - 2011-05-11 14:58:15
|
Hello Jost et al., Sorry for the delayed response, but debugging this issue has taken awhile. After additional debugging as well as working with the creator of HAProxy, I have determined that it is neither a problem with GlassFish clustering, nor with the intermediary load-balancing proxy. Rather, it seems that PHP/Java bridge uses chunking in an improper way (i.e. not supported by the specification). See http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0208.html Luckily the creator of HAProxy has been very helpful in producing a patch that works well for this particular use case. He also made some suggestions for me to pass along to you regarding alternative mechanisms to support the same thing: "You can also suggest them to take a look at WebSocket or at least to the 101/Upgrade mechanism (used by websocket). Basically they'd have to do this : GET /some-resource HTTP/1.1 Upgrade: php-java-bridge The server responds : HTTP/1.1 101 Switching protocol Upgrade: php-java-bridge Then they have a *really* bidirectional TCP connection on top of that. And if intermediaries fail, then those intermediaries are at fault." As far as your recommendation to collocate PHP and the GlassFish on the same server... doing so would break the multi-tier structure of our network, which would have many security and management implications. I would recommend that you include some information on your website indicating that this protocol is intended to be used between two applications running on the same server and that other use cases are not supported and will most likely break when using intermediary proxies. Thanks, Justin On Wed, 2011-05-04 at 20:00 +0200, php...@li... wrote: > Hi, > > please take a look at our Tomcat Cluster FAQ. It uses Apache/Tomcat, > and explains how to set up a cluster. > > Unlike your setup, the tomcat cluster runs php and java on every node, > eliminating expensive network calls. > > Although your setup may work, too, provided that your JEE server > supports HTTP/1.1 chunked connections (which it seems it doesn't), I > wouldn't run PHP in front of the load balancer. > > > Regards, > Jost Bökemeier > > > On 5/1/11, php...@li... > <php...@li...> wrote: > > I upgraded to Glassfish 3.1 and that problem seems to be fixed. However > > I'm getting the following exception whenever I have HAProxy sitting in > > between apache/php and glassfish... > > > > [#|2011-04-26T13:48:10.022-0500|SEVERE|sun-appserver2.1| > > javax.enterprise.system.container.web| > > _ThreadID=22;_ThreadName=httpSSLWorkerThread-38080-1;_RequestID=10483a26-c954-4b1f-a564-15fa7c54fd6f;|StandardWrapperValve[uibServlet]: > > PWC1406: Servlet.service() for servlet uibServlet threw exception > > java.io.IOException: Invalid chunk header > > at > > org.apache.coyote.http11.filters.ChunkedInputFilter.doRead(ChunkedInputFilter.java:171) > > at > > org.apache.coyote.http11.InternalInputBuffer.doRead(InternalInputBuffer.java:722) > > at org.apache.coyote.Request.doRead(Request.java:482) > > at > > org.apache.coyote.tomcat5.InputBuffer.realReadBytes(InputBuffer.java:342) > > at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:411) > > at org.apache.coyote.tomcat5.InputBuffer.read(InputBuffer.java:357) > > at > > org.apache.coyote.tomcat5.CoyoteInputStream.read(CoyoteInputStream.java:263) > > at php.java.bridge.Parser.read(Parser.java:94) > > at php.java.bridge.Parser.parse(Parser.java:176) > > at php.java.bridge.Request.handleRequest(Request.java:383) > > at php.java.bridge.Request.handleRequests(Request.java:500) > > at php.java.bridge.JavaBridge.handleRequests(JavaBridge.java:150) > > at > > php.java.servlet.RemoteHttpServletContextFactory.handleRequests(RemoteHttpServletContextFactory.java:262) > > at com.pedigree.lineage.web.servlets.UIBServlet.doPut(UIBServlet.java:1923) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:757) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > > at > > org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:427) > > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:333) > > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > at > > org.springframework.security.util.FilterChainProxy.doFilter(FilterChainProxy.java:169) > > at > > org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:236) > > at > > org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167) > > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) > > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > at > > com.pedigree.web.support.filters.RequestTimingFilter.doFilter(RequestTimingFilter.java:74) > > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) > > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > at > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:313) > > at > > org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:287) > > at > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218) > > at > > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648) > > at > > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593) > > at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94) > > at > > com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98) > > at > > com.sun.enterprise.ee.web.sessmgmt.SessionLockingStandardPipeline.invoke(SessionLockingStandardPipeline.java:120) > > at > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222) > > at > > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648) > > at > > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593) > > at > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587) > > at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093) > > at > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166) > > at > > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648) > > at > > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593) > > at > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587) > > at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093) > > at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:291) > > at > > com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:666) > > at > > com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:597) > > at > > com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:872) > > at > > com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341) > > at > > com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263) > > at > > com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214) > > at > > com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:382) > > at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:264) > > at > > com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106) > > > > It seems to be directly caused by HAproxy because it works fine without > > it in between. Has anyone seen this error message before? I'll try > > asking the HAproxy lists as well to see if they would know a work > > around. > > > > Thanks! > > > > On Thu, 2011-04-28 at 22:59 -0500, > > php...@li... wrote: > >> Hello, > >> Are there any additional setup changes that are needed to get PHP/Java > >> Bridge to work with a load-balanced glassfish 2.1.1 cluster? We use a > >> custom servlet using Spring Security for access control accessed by a > >> cluster of apache webservers through a reverse proxy. It works fine > >> when we setup the exact same Glassfish domain minus clustering, but > >> starts throwing bean creation exceptions (which are usually caused by > >> the JSESSIONID cookie not being sent correction) when we add in > >> clustering. > >> > >> My guess is that it is not a problem with PHP/Java Bridge, but rather > >> our setup of session listeners, but I figured I would ask if there is > >> something that I am overlooking here. Has anyone here used PHP/Java > >> Bridge with Glassfish cluster (2.1.1 or 3.1)? Bonus points if you have > >> also added Spring security to the mix! > >> > >> Thanks! > > > > > > > > ------------------------------------------------------------------------------ > > WhatsUp Gold - Download Free Network Management Software > > The most intuitive, comprehensive, and cost-effective network > > management toolset available today. Delivers lowest initial > > acquisition cost and overall TCO of any competing solution. > > http://p.sf.net/sfu/whatsupgold-sd > > _______________________________________________ > > php-java-bridge-users mailing list > > php...@li... > > https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users > > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > php-java-bridge-users mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users |