Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
On 1:59 PM, Terence M. Bandoian wrote: On 1:59 PM, Pid wrote: If you define the DataSource in GlobalNamingResources the pool will be started and stopped with the Tomcat lifecycle. Applications have their own lifecycle inside Tomcat, they are started after Tomcat (obviously) and stopped before Tomcat stops (also obviously). This is why the pool will not stop before your application, unless you do something manual to change that. If an application causes a thread to come into existence and allowing it to have the WebappClassLoader as its context classloader value, but does not shut it down, Tomcat complains. This is similar to the problem with JDBC 4.0 drivers. The API docs state: "Existing programs which currently load JDBC drivers using Class.forName() will continue to work without modification." However, if you continue reading and read closely, it becomes apparent that drivers are automatically registered with DriverManager when a database connection is created. In essence, a reference to a driver is implicitly created and it is the responsibility of the application to remove the reference. This doesn't seem like good design to me but no fault to Tomcat. -Terence Bandoian Correction. Drivers automatically register themselves with DriverManager when the driver class is loaded. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jdbc pool properties
Daniel, Your suggestion seems to have worked so far, thanks! testOnBorrow="true" and "validationQuery=SELECT 1" On Wed, Apr 4, 2012 at 8:46 AM, Daniel Mikusa wrote: > > > - Original Message - > > My db connections seem to be lost after an extended period of > > inactivity > > There could be a number of reasons that this occurs. Perhaps a network > issue is causing them to be disconnected or the database may be timing them > out. At any rate, it's not likely that the problem would be caused by the > "removeAbandoned" / "abandonedTimeout" settings, unless you application is > not properly returning connections to the connection pool. > > > https://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html#Preventing_database_connection_pool_leaks > > > > (for a web application). And the only way to get the connections to > > work > > again is to restart tomcat. > > > > My tomcat.jdbc.pool.Datasource settings have: > > > > > > > > > > > > > > > > > > You probably want to add testOnBorrow="true" and "validationQuery=SELECT > 1" (or some other valid query for your DB). See the following link for an > explanation of those properties. > > https://commons.apache.org/dbcp/configuration.html > > This will cause your connections to be validated prior to their use by > your application. Stale connections will be removed and replaced with new, > working connections. > > > > > Is it the removedAbonded and abandonedTimeout? Does it mean "after > > 60 > > seconds, remove the connection from the pool? > > No. See either of the links I've referenced above for an explanation of > these settings. > > > > > I guess what I need is a minActive setting then? > > > > There's no "minActive" setting. You have "minIdle", but I don't think > that would help here. > > Dan > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat 7 Maven plugin: deploy fails with tomcatManager status code:401, ReasonPhrase:Unauthorized
Olivier, OK. Thanks. So with the 2.0-SNAPSHOT version I am getting the same error (HTTP 401). [1] Interestingly, the plugin output makes it look like the WAR file was uploaded but when I visit the Manager, I can see that it is not deployed. Do you have any thoughts about what I can do to debug this further? I'd really like to get this working. [1] [INFO] Deploying war to http://localhost:8080/ Uploading: http://localhost:8080/manager/html/deploy?path=%2F Uploaded: http://localhost:8080/manager/html/deploy?path=%2F (9555 KB at 33760.1 KB/sec) [INFO] tomcatManager status code:401, ReasonPhrase:Unauthorized Matt On Apr 4, 2012, at 12:23 AM, Olivier Lamy wrote: > Hello, > Have a look here: > http://tomcat.apache.org/maven-plugin-2.0-SNAPSHOT/snapshot-test.html > > 2012/4/4 Matt Munz : >> Olivier, >> >> I made that change to settings.xml and now I'm getting a different error. >> [1] How can I find out where this plugin is stored? Perhaps there is a >> problem with the repository or my repository configuration. >> >> [1] >> [WARNING] The POM for >> org.apache.tomcat.maven:tomcat7-maven-plugin:jar:2.0-SNAPSHOT is missing, no >> dependency information available >> [WARNING] Failed to retrieve plugin descriptor for >> org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT: Plugin >> org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT or one of its >> dependencies could not be resolved: Failed to read artifact descriptor for >> org.apache.tomcat.maven:tomcat7-maven-plugin:jar:2.0-SNAPSHOT >> ... >> [WARNING] The POM for >> org.apache.tomcat.maven:tomcat7-maven-plugin:jar:2.0-SNAPSHOT is missing, no >> dependency information available >> ... >> [ERROR] Plugin org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT or >> one of its dependencies could not be resolved: Failed to read artifact >> descriptor for >> org.apache.tomcat.maven:tomcat7-maven-plugin:jar:2.0-SNAPSHOT: Could not >> find artifact org.apache.tomcat.maven:tomcat7-maven-plugin:pom:2.0-SNAPSHOT >> -> [Help 1] >> >> Matt Munz >> >> On Apr 2, 2012, at 11:48 PM, Olivier Lamy wrote: >> >>> Hello, >>> With version from codehaus manager url for tomcat7 is not correct. >>> (see >>> http://mojo.codehaus.org/tomcat-maven-plugin/examples/deployment-tomcat7.html) >>> >>> Regarding the plugin prefix trouble, you have two solutions to use the >>> correct version: >>> >>> * use the full cli: mvn >>> org.apache.tomcat.maven:tomcat7-maven-plugin:2.0-SNAPSHOT:deploy >>> * configure your settings.xml with the entry >>> >>> >>>org.apache.tomcat.maven >>> >>> >>> >>> HTH, >>> -- >>> Olivier Lamy >>> Talend: http://coders.talend.com >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> 2012/4/3 Matt Munz : Olivier, After switching to 2.0-SNAPSHOT, I am still getting errors :( First I got an error saying that the tomcat7 prefix was not found. [1] Then I tried "mvn tomcat:deploy -Dusername=Administrator -Dpassword=a" and I got a 403 response from the manager. [1] [ERROR] No plugin found for prefix 'tomcat7' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/Users/mattmunz/.m2/repository), central (http://repo1.maven.org/maven2)] -> [Help 1] [2] [ERROR] Failed to execute goal org.codehaus.mojo:tomcat-maven-plugin:1.1:deploy (default-cli) on project ...: Cannot invoke Tomcat manager: Server returned HTTP response code: 403 for URL: http://localhost:8080/manager/deploy?path=%2F...&war= -> [Help 1] Matt On Apr 2, 2012, at 4:16 AM, Olivier Lamy wrote: > Hello, > I have fixed few things related to deployment in trunk. > Could you test with current 2.0-SNAPSHOT ? > > Thanks > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > 2012/4/2 Matt Munz : >> Hi all, >> >> I'm trying to get the Tomcat 7 Maven plugin to work and I'm getting an >> authorization problem.[1] Here's the command that I'm running. [2] >> Here's the relevant snippet from tomcat-users.xml. [3] From the browser >> I am able to log on to the Manager with this account without problems. >> >> Any help you could provide would be greatly appreciated. >> >> [1] tomcatManager status code:401, ReasonPhrase:Unauthorized >> [2] mvn tomcat7:deploy -Dusername=Administrator -Dpassword=a >> [3] >> >> >> >> > roles="manager-gui,manager-script,manager-jmx"/> >> >> Matt Munz >> matt.m.m...@gmail.com >> >> >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.ap
RE: request.login() not persistent
> From: Jerry Malcolm [mailto:2ndgenfi...@gmail.com] > Subject: Re: request.login() not persistent > I was using: > > I changed it per your comment to: > <% response.sendRedirect( response.encodeRedirectURL( "/userhome" )); %> > It's like the logged on state was not saved in the session object. Or more likely that this particular client disabled cookies, thus requiring the sessionid to be included in the URL. Using the encodeRedirectURL() method will do that, whereas the plain refresh will not. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 7.0 doc 404
2012/4/6 Jesse Farinacci : > http://tomcat.apache.org/tomcat-7.0-doc/web-socket-howto.html > It is fixed now. Thank you. (The live site updates itself once an hour, so you'll have to wait a while). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Bug in Tomcat AJP Connector?
On 05/04/2012 22:17, Ofer Israeli wrote: > Y > > On 5 באפר 2012, at 18:58, "Konstantin Kolinko" wrote: > >> 2012/4/5 Ofer Israeli : >>> Mark Thomas wrote: On 04/04/2012 17:02, Ofer Israeli wrote: Once you have an OOME all bets are off. The JVM needs to be restarted. There is no guarantee of reliable operation after an OOME. Mark >>> >>> Hi Mark, >>> I agree that there in such a situation the JVM should be restarted, but it >>> isn't restarted by Tomcat. On the other hand, Tomcat does take some >>> precautious actions and kills the accepting thread, but in such a case it >>> should also close the socket that thread is listening on otherwise it is >>> leaving garbage around after the thread's death. >>> Do you see any reason as not to close the listening socket? >>> >> >> 1. Tomcat does not start JVM thus it cannot restart it. >> >> You need some external tool or script or admin to perform monitoring >> and (re)starts. >> >> 2. OOM can happen at a random place. Once it happens, it is likely >> that other places will also start to fail randomly. It is also likely >> that your attempts to recover will fail as well. >> >> Mark already mentioned it: "all bets are off". >> >> Best regards, >> Konstantin Kolinko >> > Hi Konstantin, > > I agree regarding the OOM bringing TC to a state where it must be restored, > but my point remains: if there is code that handles catching this exception > and terminating the thread, why not terminate gracefully by closing the > listening socket before killing the thread? And your point has been answered. After an OOM the JVM is in an unknown, unsafe state so a restart MUST occur to restore service. Closing a socket gracefully after an OOM is a bit like trying to shut one of the portholes on the Titanic, shortly after hearing a large crashing sound. There's only one place I know of where Tomcat attempts to interact with OOM conditions and this is not one of them, so I don't believe it's safe to say that Tomcat is deliberately handling this exception. NB an OOM is an Error, not an Exception - it is a subclass of VirtualMachineError, which is thrown to indicate that the Java Virtual Machine is broken or has run out of resources necessary for it to continue operating. An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. If anything, the locations where Tomcat catches a Throwable should be modified so it does *not* catch Errors, rather than continuing to do so and then attempting a trivial tidy-up. p -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: SEVERE: Unable to start cluster.
On 05/04/2012 22:01, Mark Eggers wrote:
> Response at the bottom:
>
> /mde/
>
>>
>> From: Dhaval Jaiswal
>> To: Tomcat Users List
>> Sent: Thursday, April 5, 2012 10:28 AM
>> Subject: Re: SEVERE: Unable to start cluster.
>>
>>
>> pfa server.xml
>>
>> The same i am using for all the 10 tomcats.
>>
>>
>>
>>
>> On Thu, Apr 5, 2012 at 9:55 PM, Pid wrote:
>>
>> On 05/04/2012 15:13, Dhaval Jaiswal wrote:
I have tested the below cluster manager; as per the instruction i have
changed. However, when we try to deploy the apps on tomcat it was
throwing error that
WARNING: Unable to send map start message.
Apr 5, 2012 1:37:12 PM org.apache.catalina.ha.session.BackupManager start
SEVERE: Unable to start BackupManager
java.lang.RuntimeException: Unable to start replicated map.
at
org.apache.catalina.tribes.tipis.AbstractReplicatedMap.init(AbstractReplicatedMap.java:230)
Failed to start BackupManager: java.lang.IllegalArgumentException:
Listener already
exists:{}[org.apache.catalina.tribes.tipis.LazyReplicatedMap]
i am using below server.xml for all the 10 tomcats. Do i have to change
it for every tomcat. How would i fix it.
>>> channelSendOptions="6">
>>> className="org.apache.catalina.ha.session.BackupManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true" mapSendOptions="6"/>
>>> className="org.apache.catalina.tribes.group.GroupChannel">
>>> className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.4"
port="45563"
frequency="500"
dropTime="3"/>
>>> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4000"
selectorTimeout="5000"
timeout="6"
maxThreads="6"/>
>>> className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>>> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"
timeout="6"
keepAliveCount="0"/>
>>> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
>>> className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
>>>
filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt"/>
>>> className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>>> className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>>> className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
>>>
>>>
>>> Wow. That's pretty neat, I've never seen Tomcat start up with just the
>>> cluster definition.
>>>
>>> How about you:
>>>
>>> 1) remove all comments
>>> 2) remove all passwords
>>> 3) post the whole server.xml inline in your next reply
>
>
> Dhaval,
>
>
> Please try to avoid posting in HTML. The font is sometimes difficult to read.
>
> Please don't cc me. I get the same message on the list, and with about 200
> mail messages per day on this account I might overlook stuff if I get a lot
> of duplicate messages.
>
> Please post stuff inline and not as attachments. While I got the attached
> server.xml file, the list generally strips attachments.
>
> All that being said, here are my comments:
>
>
>className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
>className="org.apache.catalina.core.JasperListener" />
>className="org.apache.catalina.mbeans.ServerLifecycleListener" />
>className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
>
> So you've removed the memory leak prevention listener from your
> server.xml? Is there any reason why you've done that?
>
>
> connectionTimeout="2"
>redirectPort="8443" />
>
> protocol="AJP/1.3"
>redirectPort="8443"
>backlog="100"
>maxThreads="4" />
>
> No URIEncoding="UTF-8" on your connectors? I checked your web site and
> there doesn't seem to be any characters that would be
> impacted. However, I was thinking that setting UTF-8 on all connectors
> is in general a good thing.
>
> 4 threads for the AJP connector with only a backlog of 100? I hope that
>
> a) your Apache HTTPD server is configured appropriately
> b) you can have this many file descriptors open
>
>
> className="org.apache.catalina.tribes.membership.McastService"
> address="228.0.0.4"
> port="45564"
>
Re: SEVERE: Unable to start cluster.
On 05/04/2012 18:28, Dhaval Jaiswal wrote: > pfa server.xml Sorry, not going to wade through all of those comments until you remove them from the XML. p -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Bug in Tomcat AJP Connector?
2012/4/6 Ofer Israeli : > Hi Konstantin, > > I agree regarding the OOM bringing TC to a state where it must be restored, > but my point remains: if there is code that handles catching this exception > and terminating the thread, why not terminate gracefully by closing the > listening socket before killing the thread? > 1. In theory one can configure several acceptor threads. Though it is not recommended. So one has to check the count before closing the socket. 2. The socket will be closed when Tomcat shuts down. Just closing the socket - what will it improve? Anyway you will need to shutdown this Tomcat instance before you can start the second one, because you'll need to free the shutdown port etc. > if there is code that handles catching this exception and terminating the > thread 3. There is no such special code. The thread terminates by itself, because its run() throws an exception and thus finishes execution. There is ThreadGroup.uncaughtException() method in JRE which by default prints the exception to stdout. If you consider to propose a patch - feel free to file an enhancement request in Bugzilla and attach it. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector warning message with native libraries
Replying to my own question.
See = COMMENT
- Original Message -
> From: Mark Eggers
> To: Tomcat Users List
> Cc:
> Sent: Thursday, April 5, 2012 12:40 PM
> Subject: Connector warning message with native libraries
>
> Folks:
>
> I'm seeing a warning in my logs when I use request.secret for the AJP
> connector when I load the APR native libraries. The warning is:
>
> WARNING: [SetAllPropertiesRule]{Server/Service/Connector}
> Setting property 'request.secret' to 'somesillypassword' did
> not find a
> matching property.
>
> I'm running a three node Tomcat cluster for testing with the following
> configuraiton:
>
> OS: Fedora 15 32 bit
> JVM: java version "1.6.0_31"
> Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
> Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
> Tomcat: 6.0.35
> Native: 1.1.22
> APR: apr-util-devel-1.3.12-1.fc15.i686 (Fedora RPM)
> SSL: openssl-devel-1.0.0g-1.fc15.i686 (Fedora RPM)
>
> Here's the snippet from my server.xml.
>
>
> redirectPort="8453"
> request.secret="somesillypassword"
> connectionTimeout="60"
> URIEncoding="UTF-8"/>
>
= COMMENT
It helps to read the fine javadoc for org.apache.coyote.ajp.AjpAprProtocol.
In there you will find a protected string called requiredSecret (much like
Tomcat 7.x).
Indeed, changing request.secret to requiredSecret when loading the native
libraries eliminates the warning.
However, a cursory glance at the online documentation didn't reveal any mention
of this requirement for the AjpAprProtocol. It's not a problem for Tomcat 7.x
obviously since this is the same attribute for both AprProtocol and
AjpAprProtocol.
However, for Tomcat 6 this presents an issue.
So a note when loading the native libraries, using AjpAprProtocol, and Tomcat 6
with the "secret" attribute:
Change request.secret="somesillypassword" on the AJP/1.3 connector definition
to requiredSecret="somesillypassword".
= COMMENT
Sorry for the bandwidth.
. . . . just my two cents.
/mde/
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
On 1:59 PM, Pid wrote: If you define the DataSource in GlobalNamingResources the pool will be started and stopped with the Tomcat lifecycle. Applications have their own lifecycle inside Tomcat, they are started after Tomcat (obviously) and stopped before Tomcat stops (also obviously). This is why the pool will not stop before your application, unless you do something manual to change that. If an application causes a thread to come into existence and allowing it to have the WebappClassLoader as its context classloader value, but does not shut it down, Tomcat complains. This is similar to the problem with JDBC 4.0 drivers. The API docs state: "Existing programs which currently load JDBC drivers using Class.forName() will continue to work without modification." However, if you continue reading and read closely, it becomes apparent that drivers are automatically registered with DriverManager when a database connection is created. In essence, a reference to a driver is implicitly created and it is the responsibility of the application to remove the reference. This doesn't seem like good design to me but no fault to Tomcat. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: request.login() not persistent
Konstantin, I was using: I changed it per your comment to: <% response.sendRedirect( response.encodeRedirectURL( "/userhome" )); %> It's working now, but I have no clue what's going on. I guess I should just be happy and move on. But I am apparently missing something major here, and I want to understand this. So please educate me a bit I completely understand the session philosophy and how the logon state is maintained in the session. When it was failing the session id did not change between the logon page and the redirect target page. So I'm assuming the session wasn't dropped. It's like the logged on state was not saved in the session object. Questions: 1) The wrote: > 2012/4/5 Jerry Malcolm <2ndgenfi...@gmail.com>: > > I am using TC 7.0 on a couple of servers. I have id/pw fields and a > > 'login' button at the top of all guest pages on my site. If the user > > clicks the login, it goes to a guest page that does the request.login() > > method call and then redirects to a protected page. If the login fails, > > the normal j_security login form stuff kicks in on the protected page and > > the user logs in the old way. > > > > OK, this worked on one server for several months. It never worked on the > > other server. On that server, the request.login() succeeded according to > > the logs. But when it redirected to the protected page, the j_security > > login form would appear. I could log in from there and everything was > > fine. > > (...) > > How do you perform your redirect? > Do you call HttpServletResponse.encodeRedirectURL( ) to encode > sessionid in the redirection URL? > > Form authentication relies on sessions. If new request does not > belong to the same session (the correct session id is not send by > client either in URL or with a cookie) then it does not have > authentication. > > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: 500 HTTP-status forwarding broken (JSP rendering + Exception occurence)
On 1:59 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manuel,
On 4/5/12 11:42 AM, manuel aldana wrote:
Inside web.xml I defined500..., so 500-status is
resolving to JSP error pages. I get inconsistent behaviour when an
Exception occurs during JSP rendering.
1) JSP syntax error (e.g. broken XML): === -> 500 status is set
correctly -> forward to jsp-error page is done correctly and 500
returned to browser
2) JSP runtime error: === ... ${model.causingNullPointerException}
... -> 200 status -> i.e. broken 500-forward to error.jsp -> I get
broken HTML inside browser
How much broken HTML do you get?
It's possible that the response has already been committed to the
client and there's no way to show the error page instead.
Check your log files for "Response already committed" or related errors.
- In 2nd case "some" of jsp is rendered and written to
output-buffer and resetting-status is prohibited (see isCommitted()
check) => i.e. there is no way forwarding to 500 status when error
occurred during runtime of JSP rendering
Correct.
I guess this is a bug (want to backup first before creating
trace-ticket)?
If this is a bug, it's in your webapp: you generate too much content
before you have any errors.
Do you know a workaround for this?
Several options (I'm sure there are more):
1. Don't throw exceptions ;)
2. Increase your output buffer (negative performance considerations)
3. Buffer the *entire* response (negative performance considerations,
requires additional code)
Honestly, #1 is the best policy IMO, since you really should have all
of your dangerous activities out of the way before you start
generating a response.
++. All processing that is likely to generate an exception should be
completed before any output is generated.
-Terence Bandoian
Currently I have workaround to have a special Filter checking for
Exceptions and including 200 status. The bad thing is that still
browser/users get returned 200 OK status, though error occurred ,
because resetting status isn't allowed.
I don't know how you will correct malformed HTML in that case.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk99wzIACgkQ9CaO5/Lv0PArgQCgxCY0TAXJffHwEbfqFYSquGnZ
q7oAni/aTXMjNnC/qbLxeQBixC1DbHW0
=S5iP
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with shutting down tomcat5.5.29
On 1:59 PM, Konstantin Kolinko wrote: 2012/4/5 Petr Hracek: What I see in the start.log file is: 2012-04-05 15:28:04,557 [main] INFO org.apache.coyote.http11.Http11BaseProtocol - Initializing Coyote HTTP/1.1 on http-8080 2012-04-05 15:28:04,560 [main] INFO org.apache.catalina.startup.Catalina - Initialization processed in 1062 ms 2012-04-05 15:28:04,727 [main] INFO org.apache.catalina.core.StandardService - Starting service Catalina 2012-04-05 15:28:04,731 [main] INFO org.apache.catalina.core.StandardEngine - Starting Servlet Engine: Apache Tomcat/5.5.27 2012-04-05 15:28:04,743 [main] INFO org.apache.catalina.core.StandardHost - XML validation disabled 2012-04-05 15:28:06,229 [main] INFO org.apache.catalina.loader.WebappClassLoader - validateJarFile(/opt/repgen/servlet/WEB-INF/lib/servlet.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class The above is bad. (Though not related to your original question). You should not have servlet.jar in your application. Servlet API is provided by Tomcat only. Tomcat had to ignore your jar. 2012-04-05 15:28:06,312 [main] INFO org.apache.coyote.http11.Http11BaseProtocol - Starting Coyote HTTP/1.1 on http-8080 2012-04-05 15:28:06,423 [main] INFO org.apache.jk.common.ChannelSocket - JK: ajp13 listening on /127.0.0.1:8009 2012-04-05 15:28:06,425 [main] INFO org.apache.jk.server.JkMain - Jk running ID=time=0/15 config=null 2012-04-05 15:28:06,453 [main] INFO org.apache.catalina.storeconfig.StoreLoader - Find registry server-registry.xml at classpath resource 2012-04-05 15:28:06,514 [main] INFO org.apache.catalina.startup.Catalina - Server startup in 1954 ms Here is mention ajp13. It is not correct one, right? The above logs mean that you do not have Tomcat-Native library, so plain java (non-Apr) implementations of connectors are used. Thus you are better to remove/comment the following line in server.xml ( When Tomcat-Native is used, startup of 5.5 would look like the following: [[[ 05.04.2012 18:47:22 org.apache.catalina.core.AprLifecycleListener init INFO: Loaded APR based Apache Tomcat Native library 1.1.22. 05.04.2012 18:47:22 org.apache.catalina.core.AprLifecycleListener init INFO: APR capabilities: IPv6 [false], sendfile [true], accept filters [false], random [true]. 05.04.2012 18:47:23 org.apache.coyote.http11.Http11AprProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 05.04.2012 18:47:23 org.apache.coyote.ajp.AjpAprProtocol init INFO: Initializing Coyote AJP/1.3 on ajp-8009 05.04.2012 18:47:23 org.apache.catalina.startup.Catalina load INFO: Initialization processed in 1578 ms 05.04.2012 18:47:23 org.apache.catalina.core.StandardService start INFO: Starting service Catalina 05.04.2012 18:47:23 org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.35 05.04.2012 18:47:23 org.apache.catalina.core.StandardHost start INFO: XML validation disabled 05.04.2012 18:47:24 org.apache.coyote.http11.Http11AprProtocol start INFO: Starting Coyote HTTP/1.1 on http-8080 05.04.2012 18:47:24 org.apache.coyote.ajp.AjpAprProtocol start INFO: Starting Coyote AJP/1.3 on ajp-8009 05.04.2012 18:47:24 org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource 05.04.2012 18:47:24 org.apache.catalina.startup.Catalina start INFO: Server startup in 1484 ms ]]] Note that protocol implementation names are "Http11AprProtocol" and "AjpAprProtocol" ) Is it possible that during the shutting down of tomcat5 stopping operation will take more then 2 minutes? It is possible, but you better take a thread dump (3 dumps separated by several seconds) to look what Tomcat is actually doing. How to do thread dumps is mentioned in the FAQ When I am commented out Listener section then during the stopping tomcat5 Failed is not mentioned but in stop.log file Exception is still there. How to avoid that Exception message will not be there? You mean "java.net.ConnectException: Connection refused" exception? It means that shutdown script cannot connect to Tomcat shutdown port to send it the shutdown command, regardless of the reason. If it is because Tomcat is already stopped (e.g. you tried to shut it down twice in a row) then it is normal and is OK. If it is because of any other reason then it is bad. Best regards, Konstantin Kolinko This may not be related to the shutdown problem but, if httpd is providing the connectivity to the user, is the on port 8080 necessary? -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
7.0 doc 404
http://tomcat.apache.org/tomcat-7.0-doc/web-socket-howto.html -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Bug in Tomcat AJP Connector?
Y On 5 באפר 2012, at 18:58, "Konstantin Kolinko" wrote: > 2012/4/5 Ofer Israeli : >> Mark Thomas wrote: >>> On 04/04/2012 17:02, Ofer Israeli wrote: >>> >>> Once you have an OOME all bets are off. The JVM needs to be restarted. >>> There is no guarantee of reliable operation after an OOME. >>> >>> Mark >> >> Hi Mark, >> I agree that there in such a situation the JVM should be restarted, but it >> isn't restarted by Tomcat. On the other hand, Tomcat does take some >> precautious actions and kills the accepting thread, but in such a case it >> should also close the socket that thread is listening on otherwise it is >> leaving garbage around after the thread's death. >> Do you see any reason as not to close the listening socket? >> > > 1. Tomcat does not start JVM thus it cannot restart it. > > You need some external tool or script or admin to perform monitoring > and (re)starts. > > 2. OOM can happen at a random place. Once it happens, it is likely > that other places will also start to fail randomly. It is also likely > that your attempts to recover will fail as well. > > Mark already mentioned it: "all bets are off". > > Best regards, > Konstantin Kolinko > Hi Konstantin, I agree regarding the OOM bringing TC to a state where it must be restored, but my point remains: if there is code that handles catching this exception and terminating the thread, why not terminate gracefully by closing the listening socket before killing the thread? Best regards, Ifer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SEVERE: Unable to start cluster.
Response at the bottom:
/mde/
>
> From: Dhaval Jaiswal
>To: Tomcat Users List
>Sent: Thursday, April 5, 2012 10:28 AM
>Subject: Re: SEVERE: Unable to start cluster.
>
>
>pfa server.xml
>
>The same i am using for all the 10 tomcats.
>
>
>
>
>On Thu, Apr 5, 2012 at 9:55 PM, Pid wrote:
>
>On 05/04/2012 15:13, Dhaval Jaiswal wrote:
>>> I have tested the below cluster manager; as per the instruction i have
>>> changed. However, when we try to deploy the apps on tomcat it was
>>> throwing error that
>>>
>>> WARNING: Unable to send map start message.
>>> Apr 5, 2012 1:37:12 PM org.apache.catalina.ha.session.BackupManager start
>>> SEVERE: Unable to start BackupManager
>>> java.lang.RuntimeException: Unable to start replicated map.
>>> at
>>> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.init(AbstractReplicatedMap.java:230)
>>>
>>> Failed to start BackupManager: java.lang.IllegalArgumentException:
>>> Listener already
>>> exists:{}[org.apache.catalina.tribes.tipis.LazyReplicatedMap]
>>>
>>>
>>>
>>> i am using below server.xml for all the 10 tomcats. Do i have to change
>>> it for every tomcat. How would i fix it.
>>>
>>>
>>>
>>> >> channelSendOptions="6">
>>> >> className="org.apache.catalina.ha.session.BackupManager"
>>> expireSessionsOnShutdown="false"
>>> notifyListenersOnReplication="true" mapSendOptions="6"/>
>>>
>>> >> className="org.apache.catalina.tribes.group.GroupChannel">
>>> >> className="org.apache.catalina.tribes.membership.McastService"
>>> address="228.0.0.4"
>>> port="45563"
>>> frequency="500"
>>> dropTime="3"/>
>>> >> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>>> address="auto"
>>> port="4000"
>>> selectorTimeout="5000"
>>> timeout="6"
>>> maxThreads="6"/>
>>>
>>> >> className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>>> >> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"
>>> timeout="6"
>>> keepAliveCount="0"/>
>>>
>>> >> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
>>> >> className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
>>>
>>>
>>> >>
>>> filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt"/>
>>> >> className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>>> >> className="org.apache.catalina.ha.session.ClusterSessionListener"/>
>>> >> className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
>>>
>>
>>
>>Wow. That's pretty neat, I've never seen Tomcat start up with just the
>>cluster definition.
>>
>>How about you:
>>
>>1) remove all comments
>>2) remove all passwords
>>3) post the whole server.xml inline in your next reply
Dhaval,
Please try to avoid posting in HTML. The font is sometimes difficult to read.
Please don't cc me. I get the same message on the list, and with about 200 mail
messages per day on this account I might overlook stuff if I get a lot of
duplicate messages.
Please post stuff inline and not as attachments. While I got the attached
server.xml file, the list generally strips attachments.
All that being said, here are my comments:
So you've removed the memory leak prevention listener from your
server.xml? Is there any reason why you've done that?
No URIEncoding="UTF-8" on your connectors? I checked your web site and
there doesn't seem to be any characters that would be
impacted. However, I was thinking that setting UTF-8 on all connectors
is in general a good thing.
4 threads for the AJP connector with only a backlog of 100? I hope that
a) your Apache HTTPD server is configured appropriately
b) you can have this many file descriptors open
You said that you use this same server.xml for all 10
Tomcats. However, in a previous message you said you were trying to
cluster 7 Tomcats (192.168.3.5 to 192.168.3.11). If you use the same
multicast address and port for all 10 Tomcats, then all 10 Tomcats
will be a part of the cluster.
> I have tested the below cluster manager; as per the instruction i have
> changed. However, when we try to deploy the apps on tomcat it was
> throwing error that
Does this mean that the cluster actually starts without your web
application? If you've modified the logging.properties file, what does
the cluster logging file say? Please post the information inline as the
mailing list tends to strip attachments.
The default dropTime is 3000 ms (3 seconds). Is your network busy
enough so that a 30 second drop time is reasonable? If it is, then
maybe a better ne
Re: 500 HTTP-status forwarding broken (JSP rendering + Exception occurence)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manuel, On 4/5/12 2:47 PM, manuel aldana wrote: > Inside JSP we have a backing model, which contains the dynamic data > to be displayed inside JSP. Itself the model is held quite simple, > but due to programming errors it can happen, that null-references > occur. This is very rare, but we need to be notified somehow (due > to explicit ERROR logging). The log to catalina.log isn't > sufficient for our log setup (we use graylog2-server). > > With bug@tomcat I meant that it error.jsp forwarding is not > consistent between an exception at the "very start" of JSP > rendering (e.g. syntax error) vs. error later during rendering. But > I agree there is no way to "revert" status codes and content once > bytes are sent to http-consumer. Right this can't possibly be attributed to a bug in Tomcat. Instead, one might say that this is simply a fact of life for streaming data applications. Your only recourse is bigger buffers. > What I will do create an interceptor which checks for the > combination of 200 status-code and exception. I'm not sure how you would scan for that, other than a filter that simply records all exceptions that are thrown (which is easy to do). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk999/8ACgkQ9CaO5/Lv0PAc6ACgsUM0qx5VN6+6496za7tUWrtr HggAn3pd1bX/Z8xlOrfBCGUummqvHQQw =ZGL3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Connector warning message with native libraries
Folks:
I'm seeing a warning in my logs when I use request.secret for the AJP
connector when I load the APR native libraries. The warning is:
WARNING: [SetAllPropertiesRule]{Server/Service/Connector}
Setting property 'request.secret' to 'somesillypassword' did not find a
matching property.
I'm running a three node Tomcat cluster for testing with the following
configuraiton:
OS: Fedora 15 32 bit
JVM: java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
Tomcat: 6.0.35
Native: 1.1.22
APR: apr-util-devel-1.3.12-1.fc15.i686 (Fedora RPM)
SSL: openssl-devel-1.0.0g-1.fc15.i686 (Fedora RPM)
If I load the native libraries with the following setenv.sh
(CATALINA_BASE and CATALINA_HOME are set in a parent script):
#!/bin/bash
JMX_PORT=9004
CATALINA_OPTS="-Djava.library.path=$CATALINA_HOME/bin/libs \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=$JMX_PORT \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTS="-Dlog4j.home=$CATALINA_BASE/logs"
export CATALINA_OPTS JAVA_OPTS
I get the WARNING message above.
If I comment out the native libraries and run the following setenv.sh
script:
#!/bin/bash
JMX_PORT=9004
# CATALINA_OPTS="-Djava.library.path=$CATALINA_HOME/bin/libs \
CATALINA_OPTS="-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=$JMX_PORT \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTS="-Dlog4j.home=$CATALINA_BASE/logs"
export CATALINA_OPTS JAVA_OPTS
I get a warning about not loading the native libraries, but no warning
about the connector.
Here's the snippet from my server.xml.
I'll post the entire server.xml if people think it's appropriate, but
since it has clustering and farm deployment in it, it's a bit long.
Here's the relevant portion of my workers.properties file:
worker.template.type=ajp13
worker.template.host=192.168.0.254
worker.template.socket_connect_timeout=5000
worker.template.socket_keepalive=true
worker.template.ping_mode=A
worker.template.ping_timeout=1
worker.template.connection_pool_minsize=0
worker.template.connection_pool_timeout=600
worker.template.reply_timeout=30
worker.template.recovery_options=3
worker.deimos.reference=worker.template
worker.deimos.port=8019
worker.lb.type=lb
worker.lb.error_escalation_time=0
worker.lb.max_reply_timeouts=10
worker.lb.balance_workers=deimos,mars,phobos
# work around a security issue
worker.lb.secret=somesillypassword
Snippets from httpd.conf:
# uses default DocumentRoot
ServerName phoenix.mdeggers.org
ServerAlias phoenix
ServerAlias localhost.localdomain
ServerAlias localhost
JkMountFile /etc/httpd/conf.d/uriworkermap.properties
And snippets from uriworkermap.properties
#
# RPets - a random pet generator / matcher / test application
#
/RPets=lb
/RPets/*=lb
Here's the really odd thing. Even with the native libraries loaded and
the warning message in catalina.out, the cluster works. I start up the
cluster and then go to http://localhost/RPets, and the
application works as expected.
If the warning is real and the attribute is discarded, I would expect
the application to be unavailable when the native libraries are loaded.
Is this just a spurious warning? I suspect that it is, because
otherwise the Apache HTTPD - Tomcat AJP (via mod_jk 1.2.32) shouldn't
work.
And yes I know, with Tomcat 6.0.35 the attribute is no longer
necessary.
I also tried this with Tomcat 6.0.29 and got the same results (and
there the attribute IS necessary to avoid a security issue).
Puzzled . . . .
/mde/
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 500 HTTP-status forwarding broken (JSP rendering + Exception occurence)
Am 05.04.12 18:07, schrieb Christopher Schultz:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manuel,
On 4/5/12 11:42 AM, manuel aldana wrote:
Inside web.xml I defined500..., so 500-status is
resolving to JSP error pages. I get inconsistent behaviour when an
Exception occurs during JSP rendering.
1) JSP syntax error (e.g. broken XML): === -> 500 status is set
correctly -> forward to jsp-error page is done correctly and 500
returned to browser
2) JSP runtime error: === ... ${model.causingNullPointerException}
... -> 200 status -> i.e. broken 500-forward to error.jsp -> I get
broken HTML inside browser
How much broken HTML do you get?
It's possible that the response has already been committed to the
client and there's no way to show the error page instead.
Check your log files for "Response already committed" or related errors.
- In 2nd case "some" of jsp is rendered and written to
output-buffer and resetting-status is prohibited (see isCommitted()
check) => i.e. there is no way forwarding to 500 status when error
occurred during runtime of JSP rendering
Correct.
I guess this is a bug (want to backup first before creating
trace-ticket)?
If this is a bug, it's in your webapp: you generate too much content
before you have any errors.
Inside JSP we have a backing model, which contains the dynamic data to
be displayed inside JSP. Itself the model is held quite simple, but due
to programming errors it can happen, that null-references occur. This is
very rare, but we need to be notified somehow (due to explicit ERROR
logging). The log to catalina.log isn't sufficient for our log setup (we
use graylog2-server).
With bug@tomcat I meant that it error.jsp forwarding is not consistent
between an exception at the "very start" of JSP rendering (e.g. syntax
error) vs. error later during rendering. But I agree there is no way to
"revert" status codes and content once bytes are sent to http-consumer.
Do you know a workaround for this?
Several options (I'm sure there are more):
1. Don't throw exceptions ;)
2. Increase your output buffer (negative performance considerations)
3. Buffer the *entire* response (negative performance considerations,
requires additional code)
Honestly, #1 is the best policy IMO, since you really should have all
of your dangerous activities out of the way before you start
generating a response.
1) see above. exception was NullPointerException, which was a plain bug
in our code.
2 + 3) not an option for us as we have high traffic volume, the problem
of exception is much more seldom, so that we don't want to sacrifice a
fix here.
Currently I have workaround to have a special Filter checking for
Exceptions and including 200 status. The bad thing is that still
browser/users get returned 200 OK status, though error occurred ,
because resetting status isn't allowed.
I don't know how you will correct malformed HTML in that case.
The malformed HTML wasn't an issue. Bad thing was that 1) we missed it
in our log-infrastructure and 2) didn't see it on apache logs (because
status was 200 OK), we monitor on 500 status codes.
What I will do create an interceptor which checks for the combination of
200 status-code and exception. Alternatively I will see how to include
tomcat logging plug to our used
https://github.com/Graylog2/graylog2-server/wiki. This is cleaner but
also higher effort, as I need to plugin logging-handling to tomcat.
Thanks for answer and happy easter.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 7.0.27 released
The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.27 This release is includes significant new features as well as a number of bug fixes compared to version 7.0.26. The notable changes include: * Support for the WebSocket protocol (RFC6455). Both streaming and message based APIs are provided and the implementation currently fully passes the Autobahn test suite. Also included are several examples. * A number of fixes to the HTTP NIO connector, particularly when using Comet. * Improve the memory leak prevention and detection code so that it works well with JVMs from IBM. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-7.0-doc/changelog.html Note that this version has 4 zip binaries: a generic one and three bundled with Tomcat native binaries for Windows operating systems running on different CPU architectures. Downloads: http://tomcat.apache.org/download-70.cgi Migration guides from Apache Tomcat 5.5.x and 6.0.x: http://tomcat.apache.org/migration.html Thank you, -- The Apache Tomcat Team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Bug in Tomcat AJP Connector?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 4/5/12 12:18 PM, Konstantin Kolinko wrote: > 2012/4/5 Christopher Schultz : >> >> On 4/5/12 11:57 AM, Konstantin Kolinko wrote: >>> 1. Tomcat does not start JVM thus it cannot restart it. >>> >>> You need some external tool or script or admin to perform >>> monitoring and (re)starts. >> >> Asking Tomcat to restart itself after OOME would be like >> expecting you to defibrillate yourself. It works in theory, but >> not in practice. >> > > Yes. It reminds me of that Bond movie > > http://www.youtube.com/watch?v=Jhm5up5NQwk :) Note that he still didn't restart his own heart... he needed help. Maybe her name was 'cron' ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk993y4ACgkQ9CaO5/Lv0PAoCgCgsRm42v55a0XGWcfnJ/FF0Do8 AcMAmwWYowivPHKEsybuLmTie7FwV8eb =2V9h -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Bug in Tomcat AJP Connector?
> -Original Message- > From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] > Sent: Thursday, April 05, 2012 10:18 AM > To: Tomcat Users List > Subject: Re: Bug in Tomcat AJP Connector? > > 2012/4/5 Christopher Schultz : > > > > On 4/5/12 11:57 AM, Konstantin Kolinko wrote: > >> 1. Tomcat does not start JVM thus it cannot restart it. > >> > >> You need some external tool or script or admin to perform > >> monitoring and (re)starts. > > > > Asking Tomcat to restart itself after OOME would be like expecting you > > to defibrillate yourself. It works in theory, but not in practice. > > > > Yes. It reminds me of that Bond movie [Filip Hanik] I would not discard this as a joke, software is headed that way, there are solutions for this today, and more of them will come tomorrow. Self healing - it's gonna be fairly important in the new paradigm > > http://www.youtube.com/watch?v=Jhm5up5NQwk > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SEVERE: Unable to start cluster.
pfa server.xml
The same i am using for all the 10 tomcats.
On Thu, Apr 5, 2012 at 9:55 PM, Pid wrote:
> On 05/04/2012 15:13, Dhaval Jaiswal wrote:
> > I have tested the below cluster manager; as per the instruction i have
> > changed. However, when we try to deploy the apps on tomcat it was
> > throwing error that
> >
> > WARNING: Unable to send map start message.
> > Apr 5, 2012 1:37:12 PM org.apache.catalina.ha.session.BackupManager start
> > SEVERE: Unable to start BackupManager
> > java.lang.RuntimeException: Unable to start replicated map.
> >at
> >
> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.init(AbstractReplicatedMap.java:230)
> >
> > Failed to start BackupManager: java.lang.IllegalArgumentException:
> > Listener already
> > exists:{}[org.apache.catalina.tribes.tipis.LazyReplicatedMap]
> >
> >
> >
> > i am using below server.xml for all the 10 tomcats. Do i have to change
> > it for every tomcat. How would i fix it.
> >
> >
> >
> > > channelSendOptions="6">
> > > className="org.apache.catalina.ha.session.BackupManager"
> > expireSessionsOnShutdown="false"
> >notifyListenersOnReplication="true"
> mapSendOptions="6"/>
> >
> > > className="org.apache.catalina.tribes.group.GroupChannel">
> > > className="org.apache.catalina.tribes.membership.McastService"
> > address="228.0.0.4"
> > port="45563"
> > frequency="500"
> > dropTime="3"/>
> > > className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> > address="auto"
> > port="4000"
> > selectorTimeout="5000"
> > timeout="6"
> > maxThreads="6"/>
> >
> > > className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
> >>
> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"
> timeout="6"
> > keepAliveCount="0"/>
> >
> > >
> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
> > >
> className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
> >
> >
> > >
> >
> filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt"/>
> > > className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
> > > className="org.apache.catalina.ha.session.ClusterSessionListener"/>
> > >
> className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
> >
>
>
> Wow. That's pretty neat, I've never seen Tomcat start up with just the
> cluster definition.
>
> How about you:
>
> 1) remove all comments
> 2) remove all passwords
> 3) post the whole server.xml inline in your next reply
>
>
> p
>
>
> --
>
> [key:62590808]
>
>
--
[image: Inline image 2]
Re: SEVERE: Unable to start cluster.
On 05/04/2012 15:13, Dhaval Jaiswal wrote:
> I have tested the below cluster manager; as per the instruction i have
> changed. However, when we try to deploy the apps on tomcat it was
> throwing error that
>
> WARNING: Unable to send map start message.
> Apr 5, 2012 1:37:12 PM org.apache.catalina.ha.session.BackupManager start
> SEVERE: Unable to start BackupManager
> java.lang.RuntimeException: Unable to start replicated map.
>at
> org.apache.catalina.tribes.tipis.AbstractReplicatedMap.init(AbstractReplicatedMap.java:230)
>
> Failed to start BackupManager: java.lang.IllegalArgumentException:
> Listener already
> exists:{}[org.apache.catalina.tribes.tipis.LazyReplicatedMap]
>
>
>
> i am using below server.xml for all the 10 tomcats. Do i have to change
> it for every tomcat. How would i fix it.
>
>
>
> channelSendOptions="6">
> className="org.apache.catalina.ha.session.BackupManager"
> expireSessionsOnShutdown="false"
>notifyListenersOnReplication="true" mapSendOptions="6"/>
>
> className="org.apache.catalina.tribes.group.GroupChannel">
> className="org.apache.catalina.tribes.membership.McastService"
> address="228.0.0.4"
> port="45563"
> frequency="500"
> dropTime="3"/>
> className="org.apache.catalina.tribes.transport.nio.NioReceiver"
> address="auto"
> port="4000"
> selectorTimeout="5000"
> timeout="6"
> maxThreads="6"/>
>
> className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"
> timeout="6"
> keepAliveCount="0"/>
>
> className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
> className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
>
>
>
> filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.css|.*\.txt"/>
> className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
> className="org.apache.catalina.ha.session.ClusterSessionListener"/>
> className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
>
Wow. That's pretty neat, I've never seen Tomcat start up with just the
cluster definition.
How about you:
1) remove all comments
2) remove all passwords
3) post the whole server.xml inline in your next reply
p
--
[key:62590808]
signature.asc
Description: OpenPGP digital signature
Re: Bug in Tomcat AJP Connector?
2012/4/5 Christopher Schultz : > > On 4/5/12 11:57 AM, Konstantin Kolinko wrote: >> 1. Tomcat does not start JVM thus it cannot restart it. >> >> You need some external tool or script or admin to perform >> monitoring and (re)starts. > > Asking Tomcat to restart itself after OOME would be like expecting you > to defibrillate yourself. It works in theory, but not in practice. > Yes. It reminds me of that Bond movie http://www.youtube.com/watch?v=Jhm5up5NQwk Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
On 04/04/2012 16:53, Hermes Flying wrote:
>>> Which is indicating that the application deployed to "/GeneralApplication"
>>> is creating a thread named "H2 Log Writer >>GENERICAPPLICATION" and never
>>> stopping it. I do not believe that this would be associated with the pool
>>> created by Tomcat as that would >>be created as a global resource available
>>> to all applications and not specific to "/GeneralApplication".
>>> I can't really say a whole lot more about what is going on, just that this
>>> strikes me as odd. If it were my app, I'd dig into this more and see what
>>> is >>creating that thread. Possibly with a profiler or thread dumps.
>
> What is happening here (as I undestand it is the following):
> 1) My application uses Tomcat's connection pool from the data source
> 2) My application uses H2 as a file database. H2 starts back end(s) thread
> which is about logging (H2 logging) and possibly other tasks and that is the
> thread that catalina complaints about
> 3) H2 remains open as long as there are open connections and is closed when
> the last connection is released
> 4) My application uses Tomcat's connection pool and as a result Tomcat
> "decides" when the data source should be disposed or when connections are
> released (not my code).
> 5) I shutdown Tomcat.
> 6) The connection pool of Tomcat has still connections (e.g. idle) and so H2
> does not shutdown. Hence it's lock file and related background threads are
> still running.
> 7) Tomcat shuts down my application but does not dispose off the connection
> pool (yet). I believe this happens because of the way Tomcat is being shut
> down (as sequence of actions I mean).
> 8) Since the connection pool has not been disposed, there are still
> connections and as a result H2 is still running
> 9) Tomcat's memory leak detection mechanism detects H2 threads started from
> GenericApplication which uses H2 and gives the report in catalina.out. So
> Tomcat gives the report first and then proceeds with the shutdown (and this
> perhaps is not correct? I can't say)
> 10) Tomcat eventually shuts down.
>
> Is this scenario as I describe it, wrong?
If you define the DataSource in GlobalNamingResources the pool will be
started and stopped with the Tomcat lifecycle.
Applications have their own lifecycle inside Tomcat, they are started
after Tomcat (obviously) and stopped before Tomcat stops (also obviously).
This is why the pool will not stop before your application, unless you
do something manual to change that.
If an application causes a thread to come into existence and allowing it
to have the WebappClassLoader as its context classloader value, but does
not shut it down, Tomcat complains.
> Should I somehow have configured the datasource to be "associated" with my
> web application instead of a generic data source?
Maybe, you could test configuring the pool Resource in the Context,
where the ResourceLink currently is.
> Why?
So it doesn't cause a leak?
> Should I have shut the data source myself? How?
> If all what I describe is reasonable this seems to me like a "racing"
> condition. How should I mediate this?
Maybe the H2 devs will fix the classloader problem.
p
> Thank you for your time.
>
>
>
> From: Daniel Mikusa
> To: Hermes Flying
> Sent: Wednesday, April 4, 2012 5:14 PM
> Subject: Re: Discrepancy between Tomcat's connection pool and tomcat's report
> on memory leaks
>
> - Original Message -
>>
>>
>> What I do is get the dataSource inside a ServletContextListener and
>> save it in servlet context (as part of a DAO Factory):
>>
>> public void contextInitialized(ServletContextEvent sce) {
>>
>> ServletContext context = sce.getServletContext();
>> DataSource dataSource = null;
>> try {
>> dataSource = (DataSource) new
>> InitialContext().lookup("java:/comp/env/jdbc/GenericDataSource");
>> context.setAttribute("daogenericfactory",
>> DAOGenericFactory.getInstance(dataSource));
>>
>> } catch (NamingException e) {
>> e.printStackTrace();
>> }
>>
>> }
>>
>>
>> The DAOGenericFactory just returns specific DAO objects passing in
>> their constructor the data source.
>> Each DAO instance has an member variable of DataSource and for action
>> to the database I do in order to get a connection:
>>
>> public Connection getConnection() throws Exception{
>> return dataSource.getConnection();
>> }
>>
>>
>> So I use the Connection this way and I always close the connections
>> in order to be returned back to the pool.
>> The only thing perhaps to mention is that I create new DAO objects
>> passing this data source (I don't reuse instances of DAO).
>> So I don't have a pool of my own. I just use DAO pattern .
>> This is happening in my web application GeneralApplication
>> Is this information adequate/clear?
>
> Definitely clear. It just doesn't seem to match up with the output from the
> log files. You're seeing
>
> SEVERE: The web application [/GeneralApplic
Re: 500 HTTP-status forwarding broken (JSP rendering + Exception occurence)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Manuel,
On 4/5/12 11:42 AM, manuel aldana wrote:
> Inside web.xml I defined 500..., so 500-status is
> resolving to JSP error pages. I get inconsistent behaviour when an
> Exception occurs during JSP rendering.
>
> 1) JSP syntax error (e.g. broken XML): === -> 500 status is set
> correctly -> forward to jsp-error page is done correctly and 500
> returned to browser
>
>
> 2) JSP runtime error: === ... ${model.causingNullPointerException}
> ... -> 200 status -> i.e. broken 500-forward to error.jsp -> I get
> broken HTML inside browser
How much broken HTML do you get?
It's possible that the response has already been committed to the
client and there's no way to show the error page instead.
Check your log files for "Response already committed" or related errors.
> - In 2nd case "some" of jsp is rendered and written to
> output-buffer and resetting-status is prohibited (see isCommitted()
> check) => i.e. there is no way forwarding to 500 status when error
> occurred during runtime of JSP rendering
Correct.
> I guess this is a bug (want to backup first before creating
> trace-ticket)?
If this is a bug, it's in your webapp: you generate too much content
before you have any errors.
> Do you know a workaround for this?
Several options (I'm sure there are more):
1. Don't throw exceptions ;)
2. Increase your output buffer (negative performance considerations)
3. Buffer the *entire* response (negative performance considerations,
requires additional code)
Honestly, #1 is the best policy IMO, since you really should have all
of your dangerous activities out of the way before you start
generating a response.
> Currently I have workaround to have a special Filter checking for
> Exceptions and including 200 status. The bad thing is that still
> browser/users get returned 200 OK status, though error occurred ,
> because resetting status isn't allowed.
I don't know how you will correct malformed HTML in that case.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk99wzIACgkQ9CaO5/Lv0PArgQCgxCY0TAXJffHwEbfqFYSquGnZ
q7oAni/aTXMjNnC/qbLxeQBixC1DbHW0
=S5iP
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Bug in Tomcat AJP Connector?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 4/5/12 11:57 AM, Konstantin Kolinko wrote: > 1. Tomcat does not start JVM thus it cannot restart it. > > You need some external tool or script or admin to perform > monitoring and (re)starts. Asking Tomcat to restart itself after OOME would be like expecting you to defibrillate yourself. It works in theory, but not in practice. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk99waMACgkQ9CaO5/Lv0PCVogCgtEiQFk+fuEAHKc3lXkNAM0Ak MrAAnR+NKO5LK4EAmxviUTnBjTJGg7Sv =5S+d -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Bug in Tomcat AJP Connector?
2012/4/5 Ofer Israeli : > Mark Thomas wrote: >> On 04/04/2012 17:02, Ofer Israeli wrote: >> >> Once you have an OOME all bets are off. The JVM needs to be restarted. >> There is no guarantee of reliable operation after an OOME. >> >> Mark > > Hi Mark, > I agree that there in such a situation the JVM should be restarted, but it > isn't restarted by Tomcat. On the other hand, Tomcat does take some > precautious actions and kills the accepting thread, but in such a case it > should also close the socket that thread is listening on otherwise it is > leaving garbage around after the thread's death. > Do you see any reason as not to close the listening socket? > 1. Tomcat does not start JVM thus it cannot restart it. You need some external tool or script or admin to perform monitoring and (re)starts. 2. OOM can happen at a random place. Once it happens, it is likely that other places will also start to fail randomly. It is also likely that your attempts to recover will fail as well. Mark already mentioned it: "all bets are off". Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
500 HTTP-status forwarding broken (JSP rendering + Exception occurence)
Inside web.xml I defined 500..., so 500-status is resolving
to JSP error pages. I get inconsistent behaviour when an Exception
occurs during JSP rendering.
1) JSP syntax error (e.g. broken XML):
===
-> 500 status is set correctly
-> forward to jsp-error page is done correctly and 500 returned to browser
2) JSP runtime error:
===
...
${model.causingNullPointerException}
...
-> 200 status
-> i.e. broken 500-forward to error.jsp
-> I get broken HTML inside browser
Second case is quite dangerous because we didn't see anything inside
logs and 200 status was presented though we had production bug. Just
accidently looking at catalina.log (stdout logging of all exception)
covered this.
I checked source-code (6.0.35):
===
core.StandardHostValue:282:
...
response.setStatus(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
connector.Response:1457
...
if (isCommitted())
return;
...
My assumption:
- In 1st case 500 forward + status setting works fine, because JSP
rendering breaks from beginning and no content is flushed to output-buffer
- In 2nd case "some" of jsp is rendered and written to output-buffer and
resetting-status is prohibited (see isCommitted() check)
=> i.e. there is no way forwarding to 500 status when error occurred
during runtime of JSP rendering
I guess this is a bug (want to backup first before creating trace-ticket)?
Do you know a workaround for this? Currently I have workaround to have a
special Filter checking for Exceptions and including 200 status. The bad
thing is that still browser/users get returned 200 OK status, though
error occurred , because resetting status isn't allowed.
Thanks for support.
--
manuel aldana
mail: maldana.g...@gmail.com | man...@aldana-online.de
blog: www.aldana-online.de
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with shutting down tomcat5.5.29
2012/4/5 Petr Hracek : > What I see in the start.log file is: > 2012-04-05 15:28:04,557 [main] INFO > org.apache.coyote.http11.Http11BaseProtocol - Initializing Coyote > HTTP/1.1 on http-8080 > 2012-04-05 15:28:04,560 [main] INFO > org.apache.catalina.startup.Catalina - Initialization processed in > 1062 ms > 2012-04-05 15:28:04,727 [main] INFO > org.apache.catalina.core.StandardService - Starting service Catalina > 2012-04-05 15:28:04,731 [main] INFO > org.apache.catalina.core.StandardEngine - Starting Servlet Engine: > Apache Tomcat/5.5.27 > 2012-04-05 15:28:04,743 [main] INFO > org.apache.catalina.core.StandardHost - XML validation disabled > 2012-04-05 15:28:06,229 [main] INFO > org.apache.catalina.loader.WebappClassLoader - > validateJarFile(/opt/repgen/servlet/WEB-INF/lib/servlet.jar) - jar not > loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: > javax/servlet/Servlet.class The above is bad. (Though not related to your original question). You should not have servlet.jar in your application. Servlet API is provided by Tomcat only. Tomcat had to ignore your jar. > 2012-04-05 15:28:06,312 [main] INFO > org.apache.coyote.http11.Http11BaseProtocol - Starting Coyote HTTP/1.1 > on http-8080 > 2012-04-05 15:28:06,423 [main] INFO > org.apache.jk.common.ChannelSocket - JK: ajp13 listening on > /127.0.0.1:8009 > 2012-04-05 15:28:06,425 [main] INFO org.apache.jk.server.JkMain - Jk > running ID=0 time=0/15 config=null > 2012-04-05 15:28:06,453 [main] INFO > org.apache.catalina.storeconfig.StoreLoader - Find registry > server-registry.xml at classpath resource > 2012-04-05 15:28:06,514 [main] INFO > org.apache.catalina.startup.Catalina - Server startup in 1954 ms > > Here is mention ajp13. It is not correct one, right? > The above logs mean that you do not have Tomcat-Native library, so plain java (non-Apr) implementations of connectors are used. Thus you are better to remove/comment the following line in server.xml ( When Tomcat-Native is used, startup of 5.5 would look like the following: [[[ 05.04.2012 18:47:22 org.apache.catalina.core.AprLifecycleListener init INFO: Loaded APR based Apache Tomcat Native library 1.1.22. 05.04.2012 18:47:22 org.apache.catalina.core.AprLifecycleListener init INFO: APR capabilities: IPv6 [false], sendfile [true], accept filters [false], random [true]. 05.04.2012 18:47:23 org.apache.coyote.http11.Http11AprProtocol init INFO: Initializing Coyote HTTP/1.1 on http-8080 05.04.2012 18:47:23 org.apache.coyote.ajp.AjpAprProtocol init INFO: Initializing Coyote AJP/1.3 on ajp-8009 05.04.2012 18:47:23 org.apache.catalina.startup.Catalina load INFO: Initialization processed in 1578 ms 05.04.2012 18:47:23 org.apache.catalina.core.StandardService start INFO: Starting service Catalina 05.04.2012 18:47:23 org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.35 05.04.2012 18:47:23 org.apache.catalina.core.StandardHost start INFO: XML validation disabled 05.04.2012 18:47:24 org.apache.coyote.http11.Http11AprProtocol start INFO: Starting Coyote HTTP/1.1 on http-8080 05.04.2012 18:47:24 org.apache.coyote.ajp.AjpAprProtocol start INFO: Starting Coyote AJP/1.3 on ajp-8009 05.04.2012 18:47:24 org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource 05.04.2012 18:47:24 org.apache.catalina.startup.Catalina start INFO: Server startup in 1484 ms ]]] Note that protocol implementation names are "Http11AprProtocol" and "AjpAprProtocol" ) > Is it possible that during the shutting down of tomcat5 stopping > operation will take more then 2 minutes? It is possible, but you better take a thread dump (3 dumps separated by several seconds) to look what Tomcat is actually doing. How to do thread dumps is mentioned in the FAQ > When I am commented out Listener section then during the stopping > tomcat5 Failed is not mentioned > but in stop.log file Exception is still there. How to avoid that > Exception message will not be there? > You mean "java.net.ConnectException: Connection refused" exception? It means that shutdown script cannot connect to Tomcat shutdown port to send it the shutdown command, regardless of the reason. If it is because Tomcat is already stopped (e.g. you tried to shut it down twice in a row) then it is normal and is OK. If it is because of any other reason then it is bad. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Need a sample server.xml file for the session replication using backup manager
On 05/04/2012 14:57, Dhaval Jaiswal wrote: > Thanks for the info. We are using sticky sessions only with BackupManager. > > See We have the current setup. > > 1 Apache + sticky sessions with mod_ajp proxy balancer in httpd.conf + 10 > tomcats. > > currently if one of our tomcat goes down the User sessions goes down, I > need to stop this quickly somehow either by using deltamanager or > Backupmanager. > > deltamanager all-to-all session replication is not feasible since our apps > is heavy and memory chocks. > > We need a simple setup where all 9 tomcats should send session replication > to 10th tomcat where app is also running. > 10th tomcat has high hardware config in terms of memory+CPU. > > So please guide us on *server.xml change for 9 tomcats* and *server.xml for > 10th Tomcat which is BackupManager*. We have sticky sessions config up and > running. That isn't the way that the backup manage works. Go and re-read my last post. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SEVERE: Unable to start cluster.
I have tested the below cluster manager; as per the instruction i have
changed. However, when we try to deploy the apps on tomcat it was throwing
error that
WARNING: Unable to send map start message.
Apr 5, 2012 1:37:12 PM org.apache.catalina.ha.session.BackupManager start
SEVERE: Unable to start BackupManager
java.lang.RuntimeException: Unable to start replicated map.
at
org.apache.catalina.tribes.tipis.AbstractReplicatedMap.init(AbstractReplicatedMap.java:230)
Failed to start BackupManager: java.lang.IllegalArgumentException:
Listener already
exists:{}[org.apache.catalina.tribes.tipis.LazyReplicatedMap]
i am using below server.xml for all the 10 tomcats. Do i have to change it
for every tomcat. How would i fix it.
On Thu, Apr 5, 2012 at 2:25 AM, Mark Eggers wrote:
> Comments inline and surrounded by === COMMENT =
>
> - Original Message -
>
> > From: Dhaval Jaiswal
> > To: Tomcat Users List
> > Cc:
> > Sent: Wednesday, April 4, 2012 12:12 PM
> > Subject: Re: SEVERE: Unable to start cluster.
> >
> >T hanks to all for sharing info. I will test it & come back to you.
> >
> > Also want to know that after starting session replication there will be a
> > huge logging in catalina.out for session information. How to minimize it
> ?
>
> === COMMENT =
>
>
> Did read my other mail concerning how to manage logging? I thought I was
> pretty explicit (and gave an example). If my example for logging.properties
> was unclear, please ask specific questions (to the list).
>
> If you want less logging, then turn down the levels. See the following
> documentation:
>
>
> http://tomcat.apache.org/tomcat-6.0-doc/logging.html#Using_java.util.logging_(default)
>
>
> === COMMENT =
>
>
> >
> > Below are the logs of catalina.out. As per the log it shows that it has
> > added member 192.168.3.18.
> >
> > Now we have a tomcat cluster group from 192.168.3.5 to 192.168.3.11.
> > However it is trying to connect to the 192.168.3.18.
> >
> >
> > 192.168.3.18 is the tomcat of another cluster. Where should i look into
> to
> > resolve this. Where to define this limit that it has to share the session
> > information from 192.168.3.5 to 192.168.3.11.
>
> === COMMENT =
>
>
> From the documentation on the web site at:
>
>
> http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#Cluster_Information
>
>
> Membership is established using multicast heartbeats. Hence, if you wish
> to subdivide your clusters, you can do this by changing the multicast IP
> address or port in the element.
>
> In other words, if you want multiple clusters change either the multicast
> address here:
>
> className="org.apache.catalina.tribes.membership.McastService"
> address="228.0.0.4"
> port="45564"
> frequency="500"
> dropTime="3000"/>
>
> to a different multicast address, or change the port in the above to a
> different port. The multicast address / port establishes the cluster group.
> The above snippet is from one of my server.xml files.
>
> You might also want to read up on how multicasting works.
>
> === COMMENT =
>
>
> >
>
> >
> >
> > INFO: Replication member
> > added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64, -88,
> 3,
> > 18}:4000,{-64, -88, 3, 18},4000, alive=18507474,id={25 -66 -54 110 84 -96
> > 79 -74 -84 -106 122 -65 -121 9 -16 5 }, payload={}, command={},
> domain={}, ]
> > Apr 5, 2012 12:31:10 AM
> > org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
> > performBasicCheck
> > INFO: Suspect member, confirmed
> > alive.[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64, -88,
> 3,
> > 18}:4000,{-64, -88, 3, 18},4000, alive=18507474,id={25 -66 -54 110 84 -96
> > 79 -74 -84 -106 122 -65 -121 9 -16 5 }, payload={}, command={},
> domain={},
> > ]]
> > Apr 5, 2012 12:32:10 AM
> > org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
> > memberDisappeared
> > INFO: Received
> >
> memberDisappeared[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64,
> > -88, 3, 18}:4000,{-64, -88, 3, 18},4000, alive=18507474,id={25 -66 -54
> 110
> > 84 -96 79 -74 -84 -106 122 -65 -121 9 -16 5 }, payload={}, command={},
> > domain={}, ]] message. Will verify.
> > Apr 5, 2012 12:32:10 AM
> > org.apache.catalina.tribes.group.interceptors.TcpFailureDetector
> > memberDisappeared
> > INFO: Verification complete. Member still
> > alive[org.apache.catalina.tribes.membership.MemberImpl[tcp://{-64, -88,
> 3,
> > 18}:4000,{-64, -88, 3, 18},4000, alive=18507474,id={25 -66 -54 110 84 -96
> > 79 -74 -84 -106 122 -65 -121 9 -16 5 }, payload={}, command={},
> domain={},
> > ]]
> > Apr 5, 2012 12:32:10
Re: Eclipse Project Files for Tomcat 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konstantin, On 4/5/12 6:50 AM, Konstantin Kolinko wrote: > There is > http://tomcat.apache.org/tomcat-7.0-doc/building.html#Building_with_Eclipse > > Maybe it is not so easy to find (and I forgot about "ant > ide-eclipse" when you asked your question). Yeah, I hadn't looked there (which was stupid on my part). I'll link my recently-added FAQ entry to that page. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk99proACgkQ9CaO5/Lv0PA6gQCgrceRlTdEKviI2iR7/NzCofvq 77wAn2KIoSFmacSusQeO24Od/GLY9LOF =EfL+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat6 - Context - aliases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Léa, On 4/4/12 2:28 PM, Léa Massiot wrote: > < Context path="/an_alias_1" docBase="/home/d1" crossContext="true" > / > Do you really need crossContext="true" here? > - This Configuration Descriptor is automatically deployed once > saved. > > - I suppressed the Webapp "w"'s "WEB-INF\context.xml" I had > created. > > - I redeployed the Webapp "w". This is the first time you mentioned webapp "w". Is that the "main" webapp? > => Now, when a user clicks on any link < a href="/an_alias_1/file_< > i>.txt"> file_< i>.txt < /a> it is successfully retrieved. Good. > => What is still problematic to me, is that, when the user clicks > on a link, the context or Webapp changes (from "w" to > "an_alias_1"). Why is that a problem? > The resources which are in "/home/d1" are available directly by > typing the following URL in a browser: > http://:8080/an_alias_1/file_< i>.txt and not > compulsorily through the Webapp "w". Isn't that what you wanted? Or, do you want everything to be exposed through /w/an_alias_1? If you want /w/an_alias_1, then re-name your context deployment descriptor: $ mv an_alias_1.xml w\#an_alias_1.xml Honestly, though, I'm not sure it makes any difference: a URL is a URL. Maybe you just want to make it "look" like the resource "belongs" to the webapp. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk99pncACgkQ9CaO5/Lv0PB1fgCeJ+kv6Y/UH9NlG4gIJYK36juZ gE8An3r6kqhEUXY8pCwvb0A9v4YEvItG =trQU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Need a sample server.xml file for the session replication using backup manager
Thanks for the info. We are using sticky sessions only with BackupManager. See We have the current setup. 1 Apache + sticky sessions with mod_ajp proxy balancer in httpd.conf + 10 tomcats. currently if one of our tomcat goes down the User sessions goes down, I need to stop this quickly somehow either by using deltamanager or Backupmanager. deltamanager all-to-all session replication is not feasible since our apps is heavy and memory chocks. We need a simple setup where all 9 tomcats should send session replication to 10th tomcat where app is also running. 10th tomcat has high hardware config in terms of memory+CPU. So please guide us on *server.xml change for 9 tomcats* and *server.xml for 10th Tomcat which is BackupManager*. We have sticky sessions config up and running. Regards, Dhaval, On Wed, Mar 21, 2012 at 2:58 PM, Mark Thomas wrote: > On 21/03/2012 09:15, Dhaval Jaiswal wrote: > > We have already server.xml(changed as per tomcat site instructions) > > in place, but it is not working properly. I will give you detail idea > > about our environment. > > > > We have 10 tomcats starting from 192.168.3.1 to 192.168.3.10. I > > wanted to make 192.168.3.10 as master/backup node, which has a > > session id information of rest 9 tomcats including 10 too. > > > > Kindly provide the clear example of server.xml of 192.168.3.10 > > (master/backup node) & rest of the 9 tomcats. > > The backup manager doesn't work the way you think it does. Consider a > four node cluster with nodes A, B, C & D. If node A has 30 primary > sessions (more on that on a sec) then 10 of them will be backed up on > node B, 10 on node C and 10 on node D. Sessions may be primary > (currently being used), backup (full copy of the primary) or proxy (no > data but knows which nodes are primary and backup). If a node isn't the > primary or a backup it will be a proxy. > > You have to use sticky sessions with the backup manager else the primary > node for the session keeps changing and that creates a lot of traffic. > > If the primary node fails, any other node can take over since they all > have either a backup or the proxy info. > > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Problem with shutting down tomcat5.5.29
What I see in the start.log file is: 2012-04-05 15:28:04,557 [main] INFO org.apache.coyote.http11.Http11BaseProtocol - Initializing Coyote HTTP/1.1 on http-8080 2012-04-05 15:28:04,560 [main] INFO org.apache.catalina.startup.Catalina - Initialization processed in 1062 ms 2012-04-05 15:28:04,727 [main] INFO org.apache.catalina.core.StandardService - Starting service Catalina 2012-04-05 15:28:04,731 [main] INFO org.apache.catalina.core.StandardEngine - Starting Servlet Engine: Apache Tomcat/5.5.27 2012-04-05 15:28:04,743 [main] INFO org.apache.catalina.core.StandardHost - XML validation disabled 2012-04-05 15:28:06,229 [main] INFO org.apache.catalina.loader.WebappClassLoader - validateJarFile(/opt/repgen/servlet/WEB-INF/lib/servlet.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class 2012-04-05 15:28:06,312 [main] INFO org.apache.coyote.http11.Http11BaseProtocol - Starting Coyote HTTP/1.1 on http-8080 2012-04-05 15:28:06,423 [main] INFO org.apache.jk.common.ChannelSocket - JK: ajp13 listening on /127.0.0.1:8009 2012-04-05 15:28:06,425 [main] INFO org.apache.jk.server.JkMain - Jk running ID=0 time=0/15 config=null 2012-04-05 15:28:06,453 [main] INFO org.apache.catalina.storeconfig.StoreLoader - Find registry server-registry.xml at classpath resource 2012-04-05 15:28:06,514 [main] INFO org.apache.catalina.startup.Catalina - Server startup in 1954 ms Here is mention ajp13. It is not correct one, right? Is it possible that during the shutting down of tomcat5 stopping operation will take more then 2 minutes? When I am commented out Listener section then during the stopping tomcat5 Failed is not mentioned but in stop.log file Exception is still there. How to avoid that Exception message will not be there? best reagrds Petr Dne 5. dubna 2012 14:19 Konstantin Kolinko napsal(a): > 2012/4/5 Petr Hracek : >> Dear all, >> >> I now that I am using pretty old version of tomcat5, but I have a >> tricky problem. >> On the server is run apache2.2.21 and tomcat5 together. tomcat5 is >> used only as servlet container and not web server. >> Both are connected together over AJP1.3 interface. >> >> In configuration file of apache2 is mentioned: >> ProxyPass /appl1 ajp://localhost:8009/appl1 >> ProxyPassReverse /appl1 ajp://localhost:8009/appl1 >> >> During the stopping of tomcat5 I can see in log files: >> /var/log/tomcat5/base/catalina.out: >> 2012-04-05 11:56:17,492 [main] INFO >> org.apache.coyote.http11.Http11BaseProtocol - Pausing Coyote HTTP/1.1 >> on http-8080 >> 2012-04-05 11:56:18,495 [main] INFO >> org.apache.catalina.core.StandardService - Stopping service Catalina >> 2012-04-05 11:56:18,520 [main] INFO >> org.apache.coyote.http11.Http11BaseProtocol - Stopping Coyote HTTP/1.1 >> on http-8080 >> 2012-04-05 11:56:18,521 [main] INFO >> org.apache.catalina.core.AprLifecycleListener - Failed shutdown of >> Apache Portable Runtime > > Tomcat-Native shared library failed to shut down. > I do not know why. Did it start? Do you use Apr versions of Tomcat > connectors? (You will see that when Tomcat starts). If you no not > need it you can comment away the "AprLifecycleListener" in server.xml. > I do not remember whether there were some specific issues in 5.5.29 - > you may look at the changelog. > > The message really does not matter much if you shut down Tomcat as a whole. > >> >> /var/log/tomcat5/base/stop.log >> Using CATALINA_BASE: /srv/www/tomcat5/base/ >> Using CATALINA_HOME: /usr/share/tomcat5 >> Using CATALINA_TMPDIR: /srv/www/tomcat5/base//temp >> Using JRE_HOME: /usr/lib/jvm/java >> 2012-04-05 11:56:19,282 [main] ERROR >> org.apache.catalina.startup.Catalina - Catalina.stop: >> java.net.ConnectException: Connection refused > > Attempt to stop Tomcat that is already stopped (and thus do not listen > on the shutdown port anymore). > >> at java.net.PlainSocketImpl.socketConnect(Native Method) >> at java.net.PlainSocketImpl.doConnect(Unknown Source) >> at java.net.PlainSocketImpl.connectToAddress(Unknown Source) >> at java.net.PlainSocketImpl.connect(Unknown Source) >> at java.net.SocksSocketImpl.connect(Unknown Source) >> at java.net.Socket.connect(Unknown Source) >> at java.net.Socket.connect(Unknown Source) >> at java.net.Socket.(Unknown Source) >> at java.net.Socket.(Unknown Source) >> at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:395) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >> at java.lang.reflect.Method.invoke(Unknown Source) >> at >> org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:344) >> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:435) >> >> in server.xml file are used tags: >> >> >> > className="org.apache.catalina.mb
Re: Tomcat6 - Context - aliases
Konstantin Kolinko wrote > > You should remove the path attribute when Context is defined in an XML > file. > The name of the xml file itself specifies the path, not the attribute. > Indeed. Thank you. Best regards. -- View this message in context: http://tomcat.10.n6.nabble.com/Tomcat6-Context-aliases-tp4678430p4689256.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: request.login() not persistent
2012/4/5 Jerry Malcolm <2ndgenfi...@gmail.com>: > I am using TC 7.0 on a couple of servers. I have id/pw fields and a > 'login' button at the top of all guest pages on my site. If the user > clicks the login, it goes to a guest page that does the request.login() > method call and then redirects to a protected page. If the login fails, > the normal j_security login form stuff kicks in on the protected page and > the user logs in the old way. > > OK, this worked on one server for several months. It never worked on the > other server. On that server, the request.login() succeeded according to > the logs. But when it redirected to the protected page, the j_security > login form would appear. I could log in from there and everything was > fine. > (...) How do you perform your redirect? Do you call HttpServletResponse.encodeRedirectURL( ) to encode sessionid in the redirection URL? Form authentication relies on sessions. If new request does not belong to the same session (the correct session id is not send by client either in URL or with a cookie) then it does not have authentication. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem with shutting down tomcat5.5.29
2012/4/5 Petr Hracek : > Dear all, > > I now that I am using pretty old version of tomcat5, but I have a > tricky problem. > On the server is run apache2.2.21 and tomcat5 together. tomcat5 is > used only as servlet container and not web server. > Both are connected together over AJP1.3 interface. > > In configuration file of apache2 is mentioned: > ProxyPass /appl1 ajp://localhost:8009/appl1 > ProxyPassReverse /appl1 ajp://localhost:8009/appl1 > > During the stopping of tomcat5 I can see in log files: > /var/log/tomcat5/base/catalina.out: > 2012-04-05 11:56:17,492 [main] INFO > org.apache.coyote.http11.Http11BaseProtocol - Pausing Coyote HTTP/1.1 > on http-8080 > 2012-04-05 11:56:18,495 [main] INFO > org.apache.catalina.core.StandardService - Stopping service Catalina > 2012-04-05 11:56:18,520 [main] INFO > org.apache.coyote.http11.Http11BaseProtocol - Stopping Coyote HTTP/1.1 > on http-8080 > 2012-04-05 11:56:18,521 [main] INFO > org.apache.catalina.core.AprLifecycleListener - Failed shutdown of > Apache Portable Runtime Tomcat-Native shared library failed to shut down. I do not know why. Did it start? Do you use Apr versions of Tomcat connectors? (You will see that when Tomcat starts). If you no not need it you can comment away the "AprLifecycleListener" in server.xml. I do not remember whether there were some specific issues in 5.5.29 - you may look at the changelog. The message really does not matter much if you shut down Tomcat as a whole. > > /var/log/tomcat5/base/stop.log > Using CATALINA_BASE: /srv/www/tomcat5/base/ > Using CATALINA_HOME: /usr/share/tomcat5 > Using CATALINA_TMPDIR: /srv/www/tomcat5/base//temp > Using JRE_HOME: /usr/lib/jvm/java > 2012-04-05 11:56:19,282 [main] ERROR > org.apache.catalina.startup.Catalina - Catalina.stop: > java.net.ConnectException: Connection refused Attempt to stop Tomcat that is already stopped (and thus do not listen on the shutdown port anymore). > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(Unknown Source) > at java.net.PlainSocketImpl.connectToAddress(Unknown Source) > at java.net.PlainSocketImpl.connect(Unknown Source) > at java.net.SocksSocketImpl.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at java.net.Socket.(Unknown Source) > at java.net.Socket.(Unknown Source) > at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:395) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:344) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:435) > > in server.xml file are used tags: > > > className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" > /> > className="org.apache.catalina.storeconfig.StoreConfigLifecycleListener"/> > > maxThreads="150" minSpareThreads="25" maxSpareThreads="75" > enableLookups="false" redirectPort="8443" acceptCount="100" > connectionTimeout="2" disableUploadTimeout="true" /> > enableLookups="false" redirectPort="8443" > protocol="AJP/1.3" address="127.0.0.1" /> > > Where I could have a problem? Any other problem besides those two messages that I commented? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: request.login() not persistent
2012/4/5 Jerry Malcolm <2ndgenfi...@gmail.com>: > Ok, finally located the zip in my downloads folder. I'm currently running > 7.0.23. But I'm still curious about how to find out the version if I > hadn't been able to locate the zip. Is the version buried somewhere in the > install folder? > catalina.jar -> \org\apache\catalina\util\ServerInfo.properties If you have *.bat files (e.g. from a zip distributive) you can run version.bat Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: request.login() not persistent
Ok, finally located the zip in my downloads folder. I'm currently running 7.0.23. But I'm still curious about how to find out the version if I hadn't been able to locate the zip. Is the version buried somewhere in the install folder? Jerry On Wed, Apr 4, 2012 at 11:44 PM, Jerry Malcolm <2ndgenfi...@gmail.com>wrote: > Chris, > > Good question on the version. But I'm not sure how to tell. Both servers > are in a directory named Tomcat 7.0. But I can't remember if that was the > default or if I forced that name. Where can I look in the install > directory to find the version? I do know that I installed both servers > around the first of December 2011. I haven't updated since then. > > You mentioned there were some known problems with using > getUserPrincipal(). It might be related. However, I was only using > getUserPrincipal() for debug purposes to show whether I was logged on or > not. The real symptom of the problem was after logging on successfully and > redirecting to another page, the login form page pops up forcing a second > login. If it's all tied together, then fine. But if the problem you > referenced only had to do with results of getUserPrincipal and nothing > else, I doubt it is related to my problem. > > If there is a newer version since December, and there are known fixes in > this area, I'll go ahead and upgrade. But I really don't want to update > and risk more instability unless there is reason to believe upgrading will > fix the problem. > > Suggestions? > > Thx > > > On Wed, Apr 4, 2012 at 7:49 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Jerry, >> >> On 4/4/12 5:31 PM, Jerry Malcolm wrote: >> > I am using TC 7.0 on a couple of servers. >> >> 7.0.what? >> >> There have been a bunch of questions about authentication and >> authorization lately involving a (somewhat) recent change when >> resources aren't protected buy a and are calling >> request.getPrincipal(). >> >> - -chris >> -BEGIN PGP SIGNATURE- >> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk987CwACgkQ9CaO5/Lv0PD9cgCgnzLbeVE97a+vPw0SWsafDpCT >> e9sAoKYPJWqf86mkd7JtbBNDkrv2Wuwb >> =K8KQ >> -END PGP SIGNATURE- >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
Re: Discrepancy between Tomcat's connection pool and tomcat's report on memory leaks
On 04/04/2012 21:59, Hermes Flying wrote: > Thank you for your explanation. I will take this to H2 but I have one > more question on your comment: > >>> Nope. It is a memory leak in the JDBC driver which is why Tomcat >>> is reporting it. When a web application shuts down, nothing >>> should be retaining a reference to the web application class >>> loader. That the JDBC driver does, is a bug in the JDBC driver. > > My question is: is this leak a general problem that should concern me > or something that is an issue only on application undeployment? You will get a memory leak when the application is stopped for any reason. If this happens at Tomcat shut down it isn't that much of an issue. At any other point it is a problem. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Eclipse Project Files for Tomcat 7
2012/4/5 Christopher Schultz : > > Mark, > > On 3/31/12 8:40 AM, Mark Thomas wrote: >> /res/ide-support/eclipse > > Also, as I've discovered: There is http://tomcat.apache.org/tomcat-7.0-doc/building.html#Building_with_Eclipse Maybe it is not so easy to find (and I forgot about "ant ide-eclipse" when you asked your question). > > $ echo "base.path=[path where downloads will be put]" > build.properties > > $ ant ide-eclipse > > Then, go to Preferences | Java/Build Path/Classpath Variables and set > the following variables: > > ANT_HOME=path to your Ant install (where lib/ant.jar can be found) > TOMCAT_LIBS_BASE=[whatever you set base.path to above] > > Note that TOMCAT_LIBS_BASE will be Eclipse-wide, so you'll want to set > it to someplace where libraries for all versions of Tomcat (trunk, > 7.0.x, etc.) can all coexist (i.e. not within one particular project > directory). > > - -chris > Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Bug in Tomcat AJP Connector?
Mark Thomas wrote: > On 04/04/2012 17:02, Ofer Israeli wrote: >> Hi all, >> >> We have recently witnessed a strange situation. Our Tomcat (6.0.35) >> listens on 2 ports: 8080 and 8009, handling HTTP and AJP >> respectively. At some point in time we found that Apache is replying >> HTTP 503s to all clients and a look at netstat showed that indeed >> Apache could not communicate with Tomcat - there were many >> connections in state SYN_SENT, that were never replied. A test of >> attempting to connect to Tomcat's 8009 port turned out to give the >> same result, so the issue was obviously in Tomcat and not Apache. >> But netstat also showed that Tomcat was listening on port 8009. >> After digging into the logs, we found that there was an Out of Memory >> exception in the JK's accept() sequence and once this exception was >> caught there was a message of "terminating thread". >> >> So although the exception is caught and handled by killing the thread >> (isn't that a little drastic?), the socket isn't closed beforehand >> and thus the OS thinks that the port is still fine (in LISTENING >> state), as although the thread is dead, the process is alive. Has >> anyone encountered this or knows if this bug is known? > > Once you have an OOME all bets are off. The JVM needs to be restarted. > There is no guarantee of reliable operation after an OOME. > > Mark Hi Mark, I agree that there in such a situation the JVM should be restarted, but it isn't restarted by Tomcat. On the other hand, Tomcat does take some precautious actions and kills the accepting thread, but in such a case it should also close the socket that thread is listening on otherwise it is leaving garbage around after the thread's death. Do you see any reason as not to close the listening socket? Ofer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
