From: <php...@li...> - 2011-05-01 07:08:56
|
Hi souds as if tomcat (see trace) has switched off port 9767. Chunked conn. wont work as users may create non serializable content. Raise log level to see why. Please see our FAQ for details. 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 > |