Re: [Php-java-bridge-users] PJB with Glassfish clustering

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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!