November 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-1569) increase / check thread pool for EJB

by Radoslav Husar (JIRA)

increase / check thread pool for EJB ------------------------------------ Key: EJBTHREE-1569 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1569 Project: EJB 3.0 Issue Type: Sub-task Reporter: Radoslav Husar Assignee: Radoslav Husar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-947) ConnectionValidator hangs when server dies

by Tim Fox (JIRA)

ConnectionValidator hangs when server dies ------------------------------------------ Key: JBREM-947 URL: http://jira.jboss.com/jira/browse/JBREM-947 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Tim Fox Fix For: 2.2.2.SP7 If the connection between client and server is pulled (pull the real cable) or the entire server suddenly dies, then the connection won't be closed from the server (unlike a kill -9 of the server where the OS will terminate that processses connections), so the client making the write() or read() on the socket won't receive an exception. In the eyes of TCP the connection is still alive and the read/write will block until the socket timeout is reached. Typically the socket timeout will be much higher than the desired failure detection time (the validation interval), but currently failure will never be detected in this situation before the socket timeout time. Remoting should not be dependent on the socket timeout for failure detection, the connetion validation and socket timeout should be possible to be configured separately. E.g. you might want to configure a socket timeout of 60 seconds, but a connection validation frequency (ping) of 5 seconds. Currently this is not possible. The current implementation gives inconsistent behaviour depending on how the server died - i.e. whether the process died (e.g. kill -9) or the cable was pulled or the entire server disappeared. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

3
9
0 / 0

[JBoss JIRA] Created: (JBREM-949) CLONE [JBREM-947] - ConnectionValidator hangs when server dies

by Ron Sigal (JIRA)

CLONE [JBREM-947] - ConnectionValidator hangs when server dies -------------------------------------------------------------- Key: JBREM-949 URL: http://jira.jboss.com/jira/browse/JBREM-949 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP7 Reporter: Tim Fox Assigned To: Ron Sigal Fix For: 2.4.0.GA If the connection between client and server is pulled (pull the real cable) or the entire server suddenly dies, then the connection won't be closed from the server (unlike a kill -9 of the server where the OS will terminate that processses connections), so the client making the write() or read() on the socket won't receive an exception. In the eyes of TCP the connection is still alive and the read/write will block until the socket timeout is reached. Typically the socket timeout will be much higher than the desired failure detection time (the validation interval), but currently failure will never be detected in this situation before the socket timeout time. Remoting should not be dependent on the socket timeout for failure detection, the connetion validation and socket timeout should be possible to be configured separately. E.g. you might want to configure a socket timeout of 60 seconds, but a connection validation frequency (ping) of 5 seconds. Currently this is not possible. The current implementation gives inconsistent behaviour depending on how the server died - i.e. whether the process died (e.g. kill -9) or the cable was pulled or the entire server disappeared. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (JBWEB-106) 400 No Host matches server name

by Samuel Mendenhall (JIRA)

400 No Host matches server name ------------------------------- Key: JBWEB-106 URL: http://jira.jboss.com/jira/browse/JBWEB-106 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Samuel Mendenhall Assigned To: Mladen Turk Priority: Minor Attachments: Mapper.java.patch HTTP 400 response on some requests. Customer received traces from requests resulting in: * normal 200 OK response * 400 Bad Request response with the message "No Host matches server name www.sj.se" The actual request data is identical in both cases. Please see Help Desk Ticket Reference URL for complete information. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-4005) Error reading web.xml with external entities when taglib is used

by Angela Roberts (JIRA)

Error reading web.xml with external entities when taglib is used ---------------------------------------------------------------- Key: JBAS-4005 URL: http://jira.jboss.com/jira/browse/JBAS-4005 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-4.0.5.GA Environment: MacOsX, JBossAS-4.0.5 Reporter: Angela Roberts Assigned To: Remy Maucherat See the sample application attached. It contains a web.xml that uses an external entity: <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE web-app [ <!ENTITY inc SYSTEM "web-include.xml">]> <web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4"> &inc; </web-app> When the first JSP of this application is called, if this JSP declares a taglib, JBoss can't find the included xml file. This is the stack trace: 18:36:57,289 ERROR [MyEntityResolver] Invalid PUBLIC ID: null 18:36:57,351 ERROR [MyEntityResolver] Invalid PUBLIC ID: null 18:36:57,358 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception java.io.FileNotFoundException: /Applications/jboss-4.0.5.GA/bin/web-include.xml at org.jboss.net.protocol.file.FileURLConnection.connect(FileURLConnection.java:94) at org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:103) at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEntityReference(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:95) at org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:132) at org.jboss.web.tomcat.tc5.jasper.TagLibCache.processWebDotXml(TagLibCache.java:162) at org.jboss.web.tomcat.tc5.jasper.TagLibCache.init(TagLibCache.java:99) at org.jboss.web.tomcat.tc5.jasper.TagLibCache.getLocation(TagLibCache.java:83) at org.apache.jasper.JspCompilationContext.getTldLocation(JspCompilationContext.java:526) at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:422) at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:492) at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1556) at org.apache.jasper.compiler.Parser.parse(Parser.java:126) at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:211) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:100) at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:155) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:295) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:276) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:264) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:563) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:305) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:613) The same application works ok on Tomcat 5.5. I believe this is related to Bug http://issues.apache.org/bugzilla/show_bug.cgi?id=34034 . This bug is already fixed on Tomcat, but the way class org.jboss.web.tomcat.tc5.jasper.TagLibCache deals with entities may be the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-3841) Occasional NPE in org.apache.commons.modeler.Registry during startup

by Rolf Arne Corneliussen (JIRA)

Occasional NPE in org.apache.commons.modeler.Registry during startup -------------------------------------------------------------------- Key: JBAS-3841 URL: http://jira.jboss.com/jira/browse/JBAS-3841 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-4.0.3 SP1 Reporter: Rolf Arne Corneliussen Assigned To: Remy Maucherat Sometimes (but less than half the times), I get the following in the log when JBoss is started: 2006-11-09 17:38:14,453 INFO [org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8080 2006-11-09 17:38:14,468 INFO [org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-8443 2006-11-09 17:38:14,468 INFO [org.apache.coyote.http11.Http11Protocol] Starting Coyote HTTP/1.1 on http-0.0.0.0-9443 2006-11-09 17:38:14,484 INFO [org.jboss.system.server.Server] JBoss (MX MicroKernel) [4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)] Started in 19s:531ms 2006-11-09 17:38:14,500 WARN [org.apache.commons.modeler.Registry] No metadata found for org.apache.coyote.RequestInfo 2006-11-09 17:38:14,500 ERROR [org.apache.commons.modeler.Registry] Error registering jboss.web:type=RequestProcessor,worker=http-0.0.0.0-8443,name=HttpRequest2 java.lang.NullPointerException at org.apache.commons.modeler.Registry.registerComponent(Registry.java:862) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.init(Http11Protocol.java:709) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.getInitData(LeaderFollowerWorkerThread.java:48) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:673) at java.lang.Thread.run(Thread.java:595) 2006-11-09 17:38:14,500 WARN [org.apache.coyote.http11.Http11Protocol] Error registering request -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-5701) HttpSession replication soak testing

by Brian Stansberry (JIRA)

HttpSession replication soak testing ------------------------------------ Key: JBAS-5701 URL: http://jira.jboss.com/jira/browse/JBAS-5701 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Test Suite, Web (Tomcat) service Reporter: Brian Stansberry Fix For: JBossAS-5.0.0.CR2 Long running tests of HttpSession replication under heavy load. Should include: 1) Letting a significant percentage of sessions passivate and later activate. 2) Letting a significant percentage of sessions expire due to time out. 3) Invalidating remaining sessions after a while (i.e. don't use any sessions for the life of test; all get used and replaced after a while). 4) Perhaps, a low (say 1/1000) probability of failover. I have some test driver code somewhere that does a lot of this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

5
6
0 / 0

[JBoss JIRA] Created: (JBAS-5775) Implement SoakTestController

by Dominik Pospisil (JIRA)

Implement SoakTestController ---------------------------- Key: JBAS-5775 URL: https://jira.jboss.org/jira/browse/JBAS-5775 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA Reporter: Dominik Pospisil Assignee: Radoslav Husar Fix For: JBossAS-5.1.0.CR1 - start with StressTestController and / or FailoverTestController - clean up the code - add attrtibute testDuration - number of seconds the test should last Test strategy: 1. start cluster 2. start lb 3. start driver 4. wait configured number of sec 5. stop everything 6. create report -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-157) Server Shutdown Latency and Session replication and Forwarding

by Shankar Pattabiraman (JIRA)

Server Shutdown Latency and Session replication and Forwarding -------------------------------------------------------------- Key: JBCLUSTER-157 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-157 Project: JBoss Clustering Issue Type: Bug Security Level: Public (Everyone can see) Environment: Java 1.5.0_05, Win XP,Red Hat 3 JBoss 4.0.5 Apache Reporter: Shankar Pattabiraman Assigned To: Brian Stansberry Priority: Minor Setup a cluster with 2 nodes. Be in a session where a server is servicing. Try to give a Control Z to kill the server while servicing. The latency involved in shutting down the server never gives a chance for the server to switch to the other. The session in the latency period of shutdown never gets successfully switched to the other node in the cluster. Apache-2 Node Jboss Cluster and a Trivial JEE Application. Check this out whether it is a configuration issue or a real issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-5785) Fix ClusteredSingleSignOn cross-context issue in Branch_4_2

by Brian Stansberry (JIRA)

Fix ClusteredSingleSignOn cross-context issue in Branch_4_2 ----------------------------------------------------------- Key: JBAS-5785 URL: https://jira.jboss.org/jira/browse/JBAS-5785 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: Backlog See parent issue. Presently assigned to Backlog as 4.2.x is lower priority for my time. If this is a priority for you, vote for this JIRA or even better volunteer to fix it. :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2008