Re: Invalid characters in request header
Is that in my control? The url is not one that appears on my website, it's something that was manually written by some client. On Sat, Sep 9, 2017 at 1:12 PM, Martynas Jusevičius wrote: > Tomcat is an HTTP sever, and if your client is sending invalid HTTP > requests, Tomcat is right to respond with 400. The solution is to fix the > client. > > On Sat, Sep 9, 2017 at 12:09 PM, Yuval Schwartz > wrote: > > > Hello Martynas, thanks. > > > > I'm not sure 404 is better than 400. > > > > Wouldn't it be preferable to validate the url before it has a chance to > > throw the exception? > > I guess my only reason for preferring this is because I don't want it > > crowding up my logs. > > I figure if I can filter it out beforehand then it's not really an > > exception? But I would be happy to hear thoughts on this as I'm still > > fairly new to programming. I'm not sure what is considered best practice > > here. > > > > Thanks. > > > > On Sat, Sep 9, 2017 at 12:24 PM, Martynas Jusevičius < > > marty...@atomgraph.com > > > wrote: > > > > > How is 404 beter than 400? > > > > > > On Sat, Sep 9, 2017 at 9:46 AM, Yuval Schwartz < > yuval.schwa...@gmail.com > > > > > > wrote: > > > > > > > Tomcat version:8.0.43 > > > > jdk1.8.0_05 > > > > > > > > Hello, > > > > > > > > I've asked a similar question in the past about illegal characters in > > the > > > > http request header (May 15, 2017). > > > > > > > > Certain users are able to send http requests to my server that > contain > > > the > > > > space character. > > > > This character is obviously not allowed. Tomcat recognizes it and > > throws > > > an > > > > IllegalArgumentException and a http response code 400 is returned to > > the > > > > client. > > > > From my logs: > > > > > > > > > > > > > > > > *Error parsing HTTP request header...* > > > > *java.lang.IllegalArgumentException: Invalid character found in the > > > > request > > > > target. The valid characters are defined in RFC 7230 and RFC 3986* > > > > > > > > Is there any way to validate the url before it reaches tomcat so > that I > > > can > > > > return a 404 if an invalid character is found in the url? I would > just > > > like > > > > to avoid exceptions being thrown where possible. > > > > > > > > Thank you. > > > > > > > > > >
Re: Invalid characters in request header
Hello Martynas, thanks. I'm not sure 404 is better than 400. Wouldn't it be preferable to validate the url before it has a chance to throw the exception? I guess my only reason for preferring this is because I don't want it crowding up my logs. I figure if I can filter it out beforehand then it's not really an exception? But I would be happy to hear thoughts on this as I'm still fairly new to programming. I'm not sure what is considered best practice here. Thanks. On Sat, Sep 9, 2017 at 12:24 PM, Martynas Jusevičius wrote: > How is 404 beter than 400? > > On Sat, Sep 9, 2017 at 9:46 AM, Yuval Schwartz > wrote: > > > Tomcat version:8.0.43 > > jdk1.8.0_05 > > > > Hello, > > > > I've asked a similar question in the past about illegal characters in the > > http request header (May 15, 2017). > > > > Certain users are able to send http requests to my server that contain > the > > space character. > > This character is obviously not allowed. Tomcat recognizes it and throws > an > > IllegalArgumentException and a http response code 400 is returned to the > > client. > > From my logs: > > > > > > > > *Error parsing HTTP request header...* > > *java.lang.IllegalArgumentException: Invalid character found in the > > request > > target. The valid characters are defined in RFC 7230 and RFC 3986* > > > > Is there any way to validate the url before it reaches tomcat so that I > can > > return a 404 if an invalid character is found in the url? I would just > like > > to avoid exceptions being thrown where possible. > > > > Thank you. > > >
Invalid characters in request header
Tomcat version:8.0.43 jdk1.8.0_05 Hello, I've asked a similar question in the past about illegal characters in the http request header (May 15, 2017). Certain users are able to send http requests to my server that contain the space character. This character is obviously not allowed. Tomcat recognizes it and throws an IllegalArgumentException and a http response code 400 is returned to the client. >From my logs: *Error parsing HTTP request header...* *java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986* Is there any way to validate the url before it reaches tomcat so that I can return a 404 if an invalid character is found in the url? I would just like to avoid exceptions being thrown where possible. Thank you.
Encode uri
Tomcat version: 8.0.43 java: 1.8.0_05 Hello, On some web browsers, clients are able to enter uri's with unescaped illegal characters (eg: "|" or pipe). This causes an IllegalArgumentException to be thrown and a 400 response code. This behavior is reported here: https://bz.apache.org/bugzilla/show_bug.cgi?id=60425 Is there anyway to encode the URI (maybe in a filter or something) so that this exception and response code is not returned, and then a normal 404 would be returned? I have tried placing the URIEncode attribute in the connector element of the server.xml file but I think this only effects how the URI is decoded. Thank you.
Re: http to https redirect 301
Thanks Andre and Mark, I updated versions and set the appropriate parameter and the redirect works as intended. I also changed my installation to utilize the CATALINA_HOME and CATALINA_BASE variables. Thank you. On Wed, May 3, 2017 at 11:10 AM, André Warnier (tomcat) wrote: > On 03.05.2017 09:23, Yuval Schwartz wrote: > >> Thanks, comments below. >> >> On Tue, May 2, 2017 at 10:43 AM, Mark Thomas wrote: >> >> On 02/05/2017 07:51, Yuval Schwartz wrote: >>> >>>> Thanks, remarks below. >>>> >>>> On Tue, May 2, 2017 at 12:12 AM, Mark Thomas wrote: >>>> >>>> On 01/05/17 14:23, Yuval Schwartz wrote: >>>>> >>>>>> Tomcat version: 8.0.22 >>>>>> jdk: 1.8.0_05 >>>>>> >>>>>> I have a webapp that uses a tomcat server behind a load balancer. >>>>>> >>>>>> I recently added a the option to connect to my webapp via https. >>>>>> >>>>>> I would like to redirect all http requests to https. >>>>>> I achieved this by implementing the instruction outlined here: >>>>>> https://elastx.zendesk.com/hc/en-us/articles/214238826- >>>>>> >>>>> Force-https-with-Tomcat >>>>> >>>>>> >>>>>> However, I notice that this performs a redirect with repsonse code 302 >>>>>> (moved temporarily). I would like the response code to be 301. >>>>>> >>>>>> I found this bug report on the matter: >>>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=59399 >>>>>> >>>>>> Does this mean that in order to achieve a 301 redirect, I need to >>>>>> >>>>> update >>> >>>> my >>>>> >>>>>> tomcat version? >>>>>> >>>>> >>>>> Yes. >>>>> >>>>> >>>> Will this automatically make the redirect use a 301 response code, or is >>>> there a setting that I need to set? >>>> >>> >>> https://tomcat.apache.org/tomcat-8.0-doc/config/realm. >>> html#Common_Attributes >>> transportGuaranteeRedirectStatus >>> >>> Is there anyway to achieve a 301 redirect without updating >>>>>> the tomcat version? >>>>>> >>>>> >>>>> Without patching Tomcat, no. And that isn't recommended. >>>>> >>>> >>> >> Just to be clear, what "isn't recommended"? Not upgrading regularly? >> > > Double negative interrogative forms are hard to answer. > What is not recommended is patching tomcat, for the reason detailed in > Mark's next paragraph below : new minor releases would overwrite your patch. > What is recommended is to keep your tomcat installation such, that > installing a new minor release does not cause grief. > There is information about that in the "/RUNNING.txt" file which comes > with every tomcat release. > > > > >> >>>>> >>>>> I actually didn't know that I should be updating minor versions >>>> >>> regularly. >>> >>>> Is there any recommendation as to the frequency that I should be doing >>>> >>> this? >>> >>> There is no fixed recommendation. However, the Tomcat team does not >>> produce patch releases, only new minor versions. It comes down to >>> whenever there is a bug or security vulnerability fixed that you care >>> about. >>> >>> Mark >>> >>> >> Thank you. >> >> >> >>> >>> >>>> >>>> Mark >>>>> >>>>> >>>> Thank you. >>>> >>>> >>>> >>>>> >>>>> - >>>>> 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 >>> >>> >>> >> > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: http to https redirect 301
Thanks, comments below. On Tue, May 2, 2017 at 10:43 AM, Mark Thomas wrote: > On 02/05/2017 07:51, Yuval Schwartz wrote: > > Thanks, remarks below. > > > > On Tue, May 2, 2017 at 12:12 AM, Mark Thomas wrote: > > > >> On 01/05/17 14:23, Yuval Schwartz wrote: > >>> Tomcat version: 8.0.22 > >>> jdk: 1.8.0_05 > >>> > >>> I have a webapp that uses a tomcat server behind a load balancer. > >>> > >>> I recently added a the option to connect to my webapp via https. > >>> > >>> I would like to redirect all http requests to https. > >>> I achieved this by implementing the instruction outlined here: > >>> https://elastx.zendesk.com/hc/en-us/articles/214238826- > >> Force-https-with-Tomcat > >>> > >>> However, I notice that this performs a redirect with repsonse code 302 > >>> (moved temporarily). I would like the response code to be 301. > >>> > >>> I found this bug report on the matter: > >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=59399 > >>> > >>> Does this mean that in order to achieve a 301 redirect, I need to > update > >> my > >>> tomcat version? > >> > >> Yes. > >> > > > > Will this automatically make the redirect use a 301 response code, or is > > there a setting that I need to set? > > https://tomcat.apache.org/tomcat-8.0-doc/config/realm. > html#Common_Attributes > transportGuaranteeRedirectStatus > > >>> Is there anyway to achieve a 301 redirect without updating > >>> the tomcat version? > >> > >> Without patching Tomcat, no. And that isn't recommended. > Just to be clear, what "isn't recommended"? Not upgrading regularly? > >> > >> > > I actually didn't know that I should be updating minor versions > regularly. > > Is there any recommendation as to the frequency that I should be doing > this? > > There is no fixed recommendation. However, the Tomcat team does not > produce patch releases, only new minor versions. It comes down to > whenever there is a bug or security vulnerability fixed that you care > about. > > Mark > Thank you. > > > > > > > >> Mark > >> > > > > Thank you. > > > > > >> > >> > >> - > >> 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: http to https redirect 301
Thanks, remarks below. On Tue, May 2, 2017 at 12:12 AM, Mark Thomas wrote: > On 01/05/17 14:23, Yuval Schwartz wrote: > > Tomcat version: 8.0.22 > > jdk: 1.8.0_05 > > > > I have a webapp that uses a tomcat server behind a load balancer. > > > > I recently added a the option to connect to my webapp via https. > > > > I would like to redirect all http requests to https. > > I achieved this by implementing the instruction outlined here: > > https://elastx.zendesk.com/hc/en-us/articles/214238826- > Force-https-with-Tomcat > > > > However, I notice that this performs a redirect with repsonse code 302 > > (moved temporarily). I would like the response code to be 301. > > > > I found this bug report on the matter: > > https://bz.apache.org/bugzilla/show_bug.cgi?id=59399 > > > > Does this mean that in order to achieve a 301 redirect, I need to update > my > > tomcat version? > > Yes. > Will this automatically make the redirect use a 301 response code, or is there a setting that I need to set? > > > Is there anyway to achieve a 301 redirect without updating > > the tomcat version? > > Without patching Tomcat, no. And that isn't recommended. > > I actually didn't know that I should be updating minor versions regularly. Is there any recommendation as to the frequency that I should be doing this? > Mark > Thank you. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
http to https redirect 301
Tomcat version: 8.0.22 jdk: 1.8.0_05 I have a webapp that uses a tomcat server behind a load balancer. I recently added a the option to connect to my webapp via https. I would like to redirect all http requests to https. I achieved this by implementing the instruction outlined here: https://elastx.zendesk.com/hc/en-us/articles/214238826-Force-https-with-Tomcat However, I notice that this performs a redirect with repsonse code 302 (moved temporarily). I would like the response code to be 301. I found this bug report on the matter: https://bz.apache.org/bugzilla/show_bug.cgi?id=59399 Does this mean that in order to achieve a 301 redirect, I need to update my tomcat version? Is there anyway to achieve a 301 redirect without updating the tomcat version? Thank you.
Re: Should I increase connectionUploadTimeout value
Hello Andre, Thanks a lot. On Wed, Dec 28, 2016 at 12:51 PM, André Warnier (tomcat) wrote: > Hi. > > On 28.12.2016 10:14, Yuval Schwartz wrote: > >> Tomcat: 8.0.22 >> Java: jdk1.8.0_05 >> Server: Amazon Linux >> >> Hello, >> >> I recently saw an IOFileUploadException on my server: >> >> org.apache.tomcat.util.http.fileupload.FileUploadBase$IOFile >> UploadException: >> Processing of multipart/form-data request failed. Timeout attempting to >> read dat >> a from the socket >> >> And later, I get this exception: >> org.apache.tomcat.util.http.fileupload.MultipartStream$Malfo >> rmedStreamException: >> Stream ended unexpectedly >> >> I allow images to be uploaded in a multipart form. >> >> I don't allow uploads greater than 1 MB. >> >> Presently, my connector element is set up with only a connectionTimeout >> attribute (set at 20 seconds) and without a connectionUploadTimeout >> attribute. >> >> I was wondering if it's necessary to set up a connectionUploadTimeout time >> greater than 20 seconds for such small file uploads? Or is it something >> else that caused this timeout? >> >> > 1) specifically : such a timeout could occur "naturally" if the connection > of the client to the server is interrupted, for whatever reason. You did > not mention what the client is seeing in that case, you only described what > you see in the log from the server side. > (That's ok, you probably don't know anyway). > I don't know at this time. But I will try to find out. > Maybe the client (the person at the uploading form side) decided to > interrupt the upload, by navigating to some other page. If there are other > "devices" in-between (routers, firewalls, proxies,..) (as there most > probably are, nowadays) they may maintain their connection to the server > for a while, even if the original client has gone. Tomcat would thus not > see the broken connection immediately, it would still be waiting for more > data to arrive on the connection, until this timeout kicks in. > Increasing the timeout in this case, would just mean that you are blocking > a tomcat resource for a while longer, for no real good reason since the > client is already gone. > > In short, my opinion : if you only see this once in a while in your logs, > I would not worry about it. It would be different if your "clients" started > complaining about having their uploads interrupted regularly. But then you > could ask them for exactly what they are seeing in the browser as an error, > and at exactly what time; and then you could have another look at the log > for that timestamp, to see if it is the same case as above. > Good point. > > > 2) generally : I must say that it is not very clear in the on-line > documentation, at > https://tomcat.apache.org/tomcat-8.5-doc/config/http.html# > Standard_Implementation > -> Standard Implementation -> connectionUploadTimeout > (and also in the similar 7.0 docs) > what exactly this timeout applies to. Is it > - the timeout before the client actually *starts* sending *any* request > body data for this upload ? > - or a timeout which applies at any time tomcat is trying to read *some* > (a chunk of) data for this part of the multipart/form-data post, after > already reading some data ? > Similarly for the "disableUploadTimeout" attribute. > I believe that the confusion may have to do with the usage of the term > "data upload" there. It seems that, maybe, using "request body" may have > been more appropriate throughout. > (Because in a way, any HTTP POST is a "data upload", even when it is not a > multipart/form-data and/or not a file). > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Should I increase connectionUploadTimeout value
Tomcat: 8.0.22 Java: jdk1.8.0_05 Server: Amazon Linux Hello, I recently saw an IOFileUploadException on my server: org.apache.tomcat.util.http.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Timeout attempting to read dat a from the socket And later, I get this exception: org.apache.tomcat.util.http.fileupload.MultipartStream$MalformedStreamException: Stream ended unexpectedly I allow images to be uploaded in a multipart form. I don't allow uploads greater than 1 MB. Presently, my connector element is set up with only a connectionTimeout attribute (set at 20 seconds) and without a connectionUploadTimeout attribute. I was wondering if it's necessary to set up a connectionUploadTimeout time greater than 20 seconds for such small file uploads? Or is it something else that caused this timeout? Thank you.
Re: Reading properties file in context.xml
Hello Antonio,
That worked. Thanks.
I added to catalina.properties file.
If I have other API keys and such that I would like to store, should I also
store them there, or does it make more sense to simply create a separate
properties file (since they aren't related to Tomcat)?
Thank you.
On Wed, Nov 2, 2016 at 4:22 PM, Antonio S. Cofiño wrote:
> Yuval,
>
> Please take alook atthe second paragraph at Tomcat config doc's:
>
> https://tomcat.apache.org/tomcat-8.0-doc/config/
>
> |You can put your properties on the
> |
>
> |$CATALINA_BASE/conf/catalina.properties|
>
> and you can do the variable sustitution in yor configuration file usin
>
> ${PropertyName}
>
>
> for example
>
> maxActive="100" maxIdle="30" maxWait="1"
>username="${MyAPP.DBUserName}"
> password="${MyApp.DBPassword}" driverClassName="com.mysql.jdbc.Driver"
>url="jdbc:mysql://localhost:3306/javatest"/>
>
>
> instead of using the properties file you can add to the JAVA_OPS or
> CATALINA_OPTS enviroment variables
>
> For example in a bash shell
>
> $ export JAVA_OPTS="-DMyAPP.DBUserName=admin -DMyAPP.DBPassword=secret"
>
> You should be condidere that the properties passed to tomcat are dumped
> (at least) to the $CATALINA_BAS/logs/catalina.out
>
> Regards
>
> Antonio
>
>
>
>
> On 02/11/16 09:38, Yuval Schwartz wrote:
>
>> Tomcat: 8.0.22
>> Java: jdk1.8.0_05
>>
>> Hello,
>>
>> I would like to store credentials that go into the Resource element of my
>> connection pool, in a properties file. (This is so I can untrack my
>> properties file when committing to a repo).
>>
>> How would I go about accessing this properties file in my
>> META-INF/context.xml file?
>>
>> What is the best location for this properties file?
>>
>> Thank you.
>>
>>
>
Reading properties file in context.xml
Tomcat: 8.0.22 Java: jdk1.8.0_05 Hello, I would like to store credentials that go into the Resource element of my connection pool, in a properties file. (This is so I can untrack my properties file when committing to a repo). How would I go about accessing this properties file in my META-INF/context.xml file? What is the best location for this properties file? Thank you.
Re: SQLExceptions after stopping Tomcat
Hello Chris,
On Sat, Sep 17, 2016 at 7:40 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Yuval,
>
> On 9/16/16 2:33 PM, Yuval Schwartz wrote:
> > Hey Chris,
> >
> > You have a line in your link that reads:
> >
> > // if you want to issue multiple queries and/or // work with
> > multiple result sets, either declare more Statement // and
> > ResultSet locals above and duplicate all cleanup logic for them, //
> > or make sure you close each object along the way before you // try
> > to re-use the reference
> >
> > I have the following code in one of my data accessing methods:
> >
> > [same ps and rs instantiating as you]
> >
> > try { ps = connection.prepareStatement(query1); rs =
> > ps.executeQuery();
> >
> > ...[process rs. (I dont close the ps or the rs at this point)]
> >
> > ps = connection.prepareStatement(query2); rs = ps.executeQuery();
> > }
> >
> > [catch and finally blocks as you specify]
> >
> > As you can see I simply reuse the ps and rs variables, without
> > closing them beforehand. Is this a problem?
>
> That depends upon your database driver. I seem to recall Oracle
> specifically being very unforgiving when it comes to failing to close
> resources. I would add explicit "close" calls to every object you are
> expecting to be finished with.
>
> > The reason this never raised a flag before is because I have
> > another database accessing method that executes two queries in the
> > same fashion and it never caused any issues.
>
> Are there any other factors involved? Maybe that other accessing
> method doesn't get called very often? Is it in a separate process
> where cleanup happens when the process completes? Do you have some
> other kind of pooling mechanism that will auto-close resources?
>
> I think it's always a good idea to follow the API's recommendations
> about closing resources when you are done with them. In the worst
> case, the close() method is a no-op and it will eventually be JIT'd
> away. In the best case, you get clean resource management.
>
>
Thanks, I found information about this in forums and made the change.
I'll also look for it in formal documentation when I have some more time.
Thanks for your help, this was most likely the issue.
> - -chris
>
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJX3XIPAAoJEBzwKT+lPKRYhKsQAJo/+GhhRAQ2y6Mqkr54Ufb5
> Wz22WHvJ15er8z/LdZ8FLzGchD7WsmgBZj8v3yeEptzoxK7rhjvoxrO7w6ZTtz7x
> 6Qogj+qa+/HeUqELnr2SkQdyrMp+aal/DEXQvMvFp+VAKrEq+x0OKeMGBvzaimsf
> xt9AWHeD5YsfRyGqvW/RFDIPFcSq83VDha2owQEcvvzNaw/DRTPTi/OubHoDuFtF
> +MCkLjXRkbYThg/ljElWivEDd2NZJP5yDtwTBAsnQeydvKVpN7vzA47tQOznbxHN
> eVhM1aPxQim1Jt3++jXT+ByGHNpiHLuhKkxwVPm8ZD6WyWgFGHp7R6w9eddnMLth
> mUhzS5HPCLYOS0x3XcuheuhybEQdWNiBh4d6dQS59+rkdU3CASPWrbwFsdEPwMq1
> 0OdDJAZ436t+EP+XJjObnT8KV9wBWFzEN3ywxhjHWdus6bmJR+O6dxlbFXYHoYdX
> fOemuIsJvjb4vl0mw9nql4kKm1MsU46gAqjP89fiCaIVPXGJjGTyqLeD48HUiNNy
> YwhSCEFcj1ucQp6vG+MU+AnvQbxwnnrymjcuDWsgMehG772zWmRsg5mT3NaK4EZr
> rbPnfyZSMkNMgGMjwCZQl8GlKlrsyIgnS/5zozPiSmldqJ0dEyKhPgxIfWpAIJiG
> K0/k2szfVtoSBaje5eIG
> =+Il1
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: SQLExceptions after stopping Tomcat
Hey Chris,
You have a line in your link that reads:
// if you want to issue multiple queries and/or
// work with multiple result sets, either declare more Statement
// and ResultSet locals above and duplicate all cleanup logic for them,
// or make sure you close each object along the way before you
// try to re-use the reference
I have the following code in one of my data accessing methods:
[same ps and rs instantiating as you]
try {
ps = connection.prepareStatement(query1);
rs = ps.executeQuery();
...[process rs. (I dont close the ps or the rs at this point)]
ps = connection.prepareStatement(query2);
rs = ps.executeQuery();
}
[catch and finally blocks as you specify]
As you can see I simply reuse the ps and rs variables, without closing them
beforehand. Is this a problem?
The reason this never raised a flag before is because I have another
database accessing method that executes two queries in the same fashion and
it never caused any issues.
Thanks a lot.
_
On Fri, Sep 16, 2016 at 7:18 PM, Yuval Schwartz
wrote:
> Thanks Chris, I'll have a look.
>
> On Fri, Sep 16, 2016 at 6:41 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Yuval,
>>
>> On 9/16/16 3:32 AM, Yuval Schwartz wrote:
>> > A few more words/questions on my issue:
>> >
>> > My Resource element used the attribute "removeAbandoned" rather
>> > than "removeAbandonedOnBorrow". I have now corrected this. Does
>> > this affect what gets logged (ie: I've had "logAbandoned" on this
>> > whole time but have not seen anything in the logs about abandoned
>> > connections, is it possible that I will now see information about
>> > abandoned threads in my logs)?
>> >
>> > "removeAbandonedOnBorrow" doesn't really solve my issue since it
>> > doesn't get to the core of the problem, how will I know to
>> > recognize when an abandoned connection has been removed so that I
>> > can correct the bad code in my application.
>>
>> My bet is on a code path that simply fails to return a connection, or
>> a code path that requests two connections and therefore deadlocks when
>> things get busy.
>>
>> Have a look at this:
>> http://blog.christopherschultz.net/index.php/2009/03/16/properly-handlin
>> g-pooled-jdbc-connections/
>> <http://blog.christopherschultz.net/index.php/2009/03/16/properly-handling-pooled-jdbc-connections/>
>>
>> It might help you track down what's going on.
>>
>> Hope that helps,
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBCAAGBQJX3BKlAAoJEBzwKT+lPKRY3RoP/AxYmD6buD7kkQF0DTWLjDa2
>> dmJSVqAj4mtxDoIeRfbMmNAUz7Y4kVq7AmHj3coPKMukk8CU4676IYgKjqXCtB7K
>> a91cR/yC5FKlGuZwIxtG1oqIUQDvg5e5j2k1hX918nFdNMjJLLoF+7xNkNauKi3/
>> rafsVD12GI34jXZLxna2gfFO6kkLAjXkHSyTU9p2+6gIzHcTd6hqAsVlqkCPGDGT
>> ODcC2nFWxqLx+snTdJRuGiU/LVxNPDBObqqKWZ3CKQQaWIQ0a7aHXe7bGq3aWsBA
>> GJHMtWpLpwyB9dpRzbTXE/Phj+WkvifUDTVtBSin1YkrQcLhaAqwViszRKl2wXnd
>> wtwYXiYo86QsHwfXLeq1GDfH0FmnGphdpVYe0J6nnSxgNb7kSTaX+FPkOaqKQD0g
>> phs41jcMipgFyOrdDVPbt2ntHOoP3VmFUqNmHnhdqOJx0xI+gQKglB4NAY/BQGvt
>> /yRdmHx3AGVLIp7nNGNKSrUK7vy/j6tynGYYMizRlnpOSZISbmVpAeDqjn5/Q27S
>> VYSPwA8UdrmB9tKAgSpXQMirTzt+PRVVD+zna4Dbe/thDyNbP/sNQn14nskCgf9y
>> aRmhC6R1j3TkjS7rzd7LLhlw69agjWm8s0roj+AVxCOX63xpm6RgDmaOUkoG+IZS
>> BJa1vpRmY21wlq6IaW5g
>> =Qvhj
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
Re: SQLExceptions after stopping Tomcat
Thanks Chris, I'll have a look. On Fri, Sep 16, 2016 at 6:41 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Yuval, > > On 9/16/16 3:32 AM, Yuval Schwartz wrote: > > A few more words/questions on my issue: > > > > My Resource element used the attribute "removeAbandoned" rather > > than "removeAbandonedOnBorrow". I have now corrected this. Does > > this affect what gets logged (ie: I've had "logAbandoned" on this > > whole time but have not seen anything in the logs about abandoned > > connections, is it possible that I will now see information about > > abandoned threads in my logs)? > > > > "removeAbandonedOnBorrow" doesn't really solve my issue since it > > doesn't get to the core of the problem, how will I know to > > recognize when an abandoned connection has been removed so that I > > can correct the bad code in my application. > > My bet is on a code path that simply fails to return a connection, or > a code path that requests two connections and therefore deadlocks when > things get busy. > > Have a look at this: > http://blog.christopherschultz.net/index.php/2009/03/16/properly-handlin > g-pooled-jdbc-connections/ > > It might help you track down what's going on. > > Hope that helps, > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJX3BKlAAoJEBzwKT+lPKRY3RoP/AxYmD6buD7kkQF0DTWLjDa2 > dmJSVqAj4mtxDoIeRfbMmNAUz7Y4kVq7AmHj3coPKMukk8CU4676IYgKjqXCtB7K > a91cR/yC5FKlGuZwIxtG1oqIUQDvg5e5j2k1hX918nFdNMjJLLoF+7xNkNauKi3/ > rafsVD12GI34jXZLxna2gfFO6kkLAjXkHSyTU9p2+6gIzHcTd6hqAsVlqkCPGDGT > ODcC2nFWxqLx+snTdJRuGiU/LVxNPDBObqqKWZ3CKQQaWIQ0a7aHXe7bGq3aWsBA > GJHMtWpLpwyB9dpRzbTXE/Phj+WkvifUDTVtBSin1YkrQcLhaAqwViszRKl2wXnd > wtwYXiYo86QsHwfXLeq1GDfH0FmnGphdpVYe0J6nnSxgNb7kSTaX+FPkOaqKQD0g > phs41jcMipgFyOrdDVPbt2ntHOoP3VmFUqNmHnhdqOJx0xI+gQKglB4NAY/BQGvt > /yRdmHx3AGVLIp7nNGNKSrUK7vy/j6tynGYYMizRlnpOSZISbmVpAeDqjn5/Q27S > VYSPwA8UdrmB9tKAgSpXQMirTzt+PRVVD+zna4Dbe/thDyNbP/sNQn14nskCgf9y > aRmhC6R1j3TkjS7rzd7LLhlw69agjWm8s0roj+AVxCOX63xpm6RgDmaOUkoG+IZS > BJa1vpRmY21wlq6IaW5g > =Qvhj > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: SQLExceptions after stopping Tomcat
A few more words/questions on my issue: My Resource element used the attribute "removeAbandoned" rather than "removeAbandonedOnBorrow". I have now corrected this. Does this affect what gets logged (ie: I've had "logAbandoned" on this whole time but have not seen anything in the logs about abandoned connections, is it possible that I will now see information about abandoned threads in my logs)? "removeAbandonedOnBorrow" doesn't really solve my issue since it doesn't get to the core of the problem, how will I know to recognize when an abandoned connection has been removed so that I can correct the bad code in my application. Thanks. On Thu, Sep 15, 2016 at 11:30 AM, Yuval Schwartz wrote: > Hello, > > I'd rather narrow down the problem a bit more before upgrading (to make > sure that that's the issue). > > It happened again, this time I took a thread dump of the instance that > went down (actually, it's only the DB connection pool that becomes > unresponsive but I remove the instance from my load balancer when this > happens). > > The thread dump shows pretty much the same things that the logs showed > when I shutdown tomcat: a very long list of a lot of stack traces which all > get stuck when trying to access the connection pool. An example from the > thread dump: > > "http-apr-8080-exec-805" #840 daemon prio=5 os_prio=0 > tid=0x7f50d00c1800 nid=0x5fbc waiting on condition [0x7f50c62e7000] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xec44cf38> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport. > java:175) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ > ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > at org.apache.tomcat.dbcp.pool2.impl.LinkedBlockingDeque. > takeFirst(LinkedBlockingDeque.java:582) > at org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool. > borrowObject(GenericObjectPool.java:439) > at org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool. > borrowObject(GenericObjectPool.java:360) > at org.apache.tomcat.dbcp.dbcp2.PoolingDataSource.getConnection( > PoolingDataSource.java:118) > at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection( > BasicDataSource.java:1412) > > Questions: > 1) What order does a thread dump print in? That is, I'd like to know what > the first thread was in my thread dump (temporally) so that I might know > which thread caused the actual issue. Is this the beginning of the thread > dump or the end? > > 2) The thread dump was so long that I can't see the beginning of it. Does > anyone know how to get the thread dump in bits and pieces so the beginning > doesn't get cut off when it's long? > > Possible causes: > Is it possible that someone is acting maliciously and intentionally > hitting certain pages many times to cause the pool to lock up? > I think this because if I just take a thread dump when my application is > functioning, then it doesn't show anything suspicious. > This leads me to believe that the problem is not cumulative but rather > happens all at once. > Then when I take a look at the problematic thread dump and see so many > stack traces that access my database, it leads me to think that they are > accessed all at once at the time that the pool locks up. > > Any thoughts? > > Thanks a lot. > _ > > > On Mon, Sep 12, 2016 at 9:37 PM, Mark Thomas wrote: > >> On 12/09/2016 19:02, Yuval Schwartz wrote: >> > Hey Mark, thanks a lot. >> > >> > On Mon, Sep 12, 2016 at 4:42 PM, Mark Thomas wrote: >> > >> >> On 12/09/2016 11:54, Yuval Schwartz wrote: >> >> >> >> >> It might also be a bug in the connection pool that has been fixed. >> >> Upgrading to the latest 8.0.x (or better still the latest 8.5.x) should >> >> address that. >> >> >> > >> > I'll look for a bug report on this (although I haven't found anything >> as of >> > yet). >> >> There was one around XA connections that could result in a leak. The >> others, you'd need to dig into the DBCP change log and Jira for. >> >> > I wouldn't mind upgrading but do you think this could be a bug? I've >> been >> > running my application with this setup for about 8 months; the problem >> only >> > started in the last week. >> >> That begs the question what changed a week ago? >> >> Mark >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
Re: SQLExceptions after stopping Tomcat
Hello, I'd rather narrow down the problem a bit more before upgrading (to make sure that that's the issue). It happened again, this time I took a thread dump of the instance that went down (actually, it's only the DB connection pool that becomes unresponsive but I remove the instance from my load balancer when this happens). The thread dump shows pretty much the same things that the logs showed when I shutdown tomcat: a very long list of a lot of stack traces which all get stuck when trying to access the connection pool. An example from the thread dump: "http-apr-8080-exec-805" #840 daemon prio=5 os_prio=0 tid=0x7f50d00c1800 nid=0x5fbc waiting on condition [0x7f50c62e7000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xec44cf38> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at org.apache.tomcat.dbcp.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:582) at org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:439) at org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:360) at org.apache.tomcat.dbcp.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:118) at org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1412) Questions: 1) What order does a thread dump print in? That is, I'd like to know what the first thread was in my thread dump (temporally) so that I might know which thread caused the actual issue. Is this the beginning of the thread dump or the end? 2) The thread dump was so long that I can't see the beginning of it. Does anyone know how to get the thread dump in bits and pieces so the beginning doesn't get cut off when it's long? Possible causes: Is it possible that someone is acting maliciously and intentionally hitting certain pages many times to cause the pool to lock up? I think this because if I just take a thread dump when my application is functioning, then it doesn't show anything suspicious. This leads me to believe that the problem is not cumulative but rather happens all at once. Then when I take a look at the problematic thread dump and see so many stack traces that access my database, it leads me to think that they are accessed all at once at the time that the pool locks up. Any thoughts? Thanks a lot. _ On Mon, Sep 12, 2016 at 9:37 PM, Mark Thomas wrote: > On 12/09/2016 19:02, Yuval Schwartz wrote: > > Hey Mark, thanks a lot. > > > > On Mon, Sep 12, 2016 at 4:42 PM, Mark Thomas wrote: > > > >> On 12/09/2016 11:54, Yuval Schwartz wrote: > > > > >> It might also be a bug in the connection pool that has been fixed. > >> Upgrading to the latest 8.0.x (or better still the latest 8.5.x) should > >> address that. > >> > > > > I'll look for a bug report on this (although I haven't found anything as > of > > yet). > > There was one around XA connections that could result in a leak. The > others, you'd need to dig into the DBCP change log and Jira for. > > > I wouldn't mind upgrading but do you think this could be a bug? I've been > > running my application with this setup for about 8 months; the problem > only > > started in the last week. > > That begs the question what changed a week ago? > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: SQLExceptions after stopping Tomcat
Hey Mark, thanks a lot. On Mon, Sep 12, 2016 at 4:42 PM, Mark Thomas wrote: > On 12/09/2016 11:54, Yuval Schwartz wrote: > > Hello, > > > > Tomcat: 8.0.22 > > Java: jdk1.8.0_05 > > Server: Amazon Linux > > > > My web application looses access to the database after about 24hrs of > > running (probably dependent on amount of users, not time). > > > > No messages/exceptions are printed to the console or log files. > > > > > Any ideas as to what is going on? > > Some form of connection leak? > > For configuration options to fix the leak and track down the source see: > > http://tomcat.apache.org/tomcat-8.0-doc/jndi-datasource-examples-howto. > html#Preventing_database_connection_pool_leaks > > You probably want to use logAbandoned="true" to find the source of any > I actually already have this enabled (and had it enabled when reporting the issue to this group. But good to know that it slows things down, I will disable in the future. > leaks (it will slow things down so disable once you have fixed any leaks) > > It might also be a bug in the connection pool that has been fixed. > Upgrading to the latest 8.0.x (or better still the latest 8.5.x) should > address that. > I'll look for a bug report on this (although I haven't found anything as of yet). I wouldn't mind upgrading but do you think this could be a bug? I've been running my application with this setup for about 8 months; the problem only started in the last week. > > Mark > > > I took a thread dump, but I'm not too good at analyzing those. If anyone > > has any recommendations as to what to look out for in the thread dump I'd > > be interested in hearing it. > > > > Thank you. > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
SQLExceptions after stopping Tomcat
Hello,
Tomcat: 8.0.22
Java: jdk1.8.0_05
Server: Amazon Linux
My web application looses access to the database after about 24hrs of
running (probably dependent on amount of users, not time).
No messages/exceptions are printed to the console or log files.
When I stop tomcat, then I get a few "INFO" message
("org.apache.catalina.core.StandardWrapper.unload Waiting for [number]
instance(s) to be deallocated for Servlet")
followed by a long list of all the SQLExceptions ("cannot get a connection,
general error") and Warnings
("org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads
The web application is still processing a request that has yet to
finish...").
I think the Servlet specified in the INFO messages, the stack trace of the
SQLExceptions and the stack trace of the Warnings is just specific to
whichever Servlet was called and not to which Servlet/method is at the root
of what is causing this issue.
I assume this is something in my application. I have looked over changes
that I made to the code recently and haven't found anything (all
connections, Statements, ResultSets are closed after being used).
The beginning of the stack trace that appears after the warning:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
org.apache.tomcat.dbcp.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:582)
org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:439)
org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:360)
org.apache.tomcat.dbcp.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:118)
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1412)
The beginning of the stack trace that appears after the SQLException:
at
org.apache.tomcat.dbcp.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:130)
at
org.apache.tomcat.dbcp.dbcp2.BasicDataSource.getConnection(BasicDataSource.java:1412)
at data.ConnectionPool.getConnection(ConnectionPool.java:64)
...
and then:
Caused by: java.lang.InterruptedException
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:2014)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2048)
at
org.apache.tomcat.dbcp.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:582)
at
org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:439)
at
org.apache.tomcat.dbcp.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:360)
at
org.apache.tomcat.dbcp.dbcp2.PoolingDataSource.getConnection(PoolingDataSource.java:118)
Any ideas as to what is going on?
I took a thread dump, but I'm not too good at analyzing those. If anyone
has any recommendations as to what to look out for in the thread dump I'd
be interested in hearing it.
Thank you.
Re: Restrict access to manager app by IP
Thanks a lot for your replies. For now, I removed the "path" attribute from the Context elements but left the xml file in Catalina/[hostname]. When I have some more time, I will move to within my application (META-INF/context.xml) since that seems to be the consensus here. Thank you. On Wed, Sep 7, 2016 at 8:45 PM, Mark Thomas wrote: > On 07/09/2016 18:43, Jeffrey Janner wrote: > > > > > >> -Original Message- > >> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > >> Sent: Tuesday, September 06, 2016 12:30 PM > >> To: Tomcat Users List > >> Subject: Re: Restrict access to manager app by IP > >> > > Yuval, > > > > On 9/2/16 9:29 AM, Yuval Schwartz wrote: > >>>> Thanks. I'll give it a shot and let you guys know how it goes. Any > >>>> input on whether I should put this in my applications context.xml > >>>> or in my [host] directory? > > > > I would do it in the application. Unless you have a particular reason > > to manually-place the application's context.xml file into > > conf/[engine]/[host]/[app].xml, allow Tomcat to do that for you. > > > > -chris > > > >> Chris - > > > >> Isn't the Tomcat "/manager" an app separate from the user's webapp? > Thus the need for the manager.xml in conf/[engine]/[host] directory? > > It is an application like any other so you can use: > > $CATALINA_BASE/webapps/manager/META-INF/context.xml > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Restricted Access to Tomcat Manager Caused Database Issues
Hello, Tomcat: 8.0.22 Java: jdk1.8.0_05 I recently restricted access to my Tomcat Manager App by: 1) Changing the name of the manager app. 2) Block access to the manager app by IP address. I did the following: A) Stopped Tomcat B) Simply renamed the manager app in $CATALINA_BASE/webapps by executing the linux command "mv manager somename". C) Adding a file to the path $CATALINA_BASE/conf/Catalina/[hostname] named "somename.xml" which contained the following context element to restrict access to the manager app: D) Start Tomcat This caused my web application to loose access to the database (as if the web applications Context element located in /webapps/myapp/META-INF/context.xml was overridden or something). Does anyone have any suggestions on what's going on? My host is called localhost. Thanks. adding a file to the path $CATALINA_BASE/conf/Catalina/[hostname] named
Re: Restrict access to manager app by IP
Hello Peter, Thanks. I'll give it a shot and let you guys know how it goes. Any input on whether I should put this in my applications context.xml or in my [host] directory? Thank you. On Fri, Sep 2, 2016 at 4:24 PM, Kreuser, Peter wrote: > Hi Yuval, > > > > -Ursprüngliche Nachricht- > > Von: Yuval Schwartz [mailto:yuval.schwa...@gmail.com] > > Gesendet: Freitag, 2. September 2016 13:28 > > An: Tomcat Users List > > Betreff: Restrict access to manager app by IP > > > > Tomcat: 8.0.22 > > JDK: 1.8.0_05 > > > > Hello, > > > > I am currently running a web application. > > > > I would like to restrict access to the manager app (it is currently > being hit by spammers every so often who are unable to connect (get a > message "...an attempt was made to authenticate the locked user")). > > > > I was thinking of adding a "manager.xml" file to > > $CATALINA_BASE/conf/[enginename]/[hostname]/ > that will contain the following context container: > > > > className="org.apache.catalina.valves.RemoteAddrValve" > > allow="[my_ip]"/> > > > > > > Is this the correct way to achieve my goal of limiting access to the > manager app to only my IP. > > > > Of course, I do not want the rest of my webapp's access limited (which > is on the ROOT path). I only want access to the manager app limited. > > > > (I know I can also place the context container in my webapp's > META-INF/context.xml file, is there any preference to doing this over what > I suggested above?) > > > > Thank you > > _ > > > > That's the proposed solution for it. I don't think that you need the > docbase - unless you don't use the default location. > > I think you will have to quote the . in the ip with backslash, like > allow="10\.100\.17\.33|10\.100\.88\.92" /> > > Best regards > > Peter >
Restrict access to manager app by IP
Tomcat: 8.0.22 JDK: 1.8.0_05 Hello, I am currently running a web application. I would like to restrict access to the manager app (it is currently being hit by spammers every so often who are unable to connect (get a message "...an attempt was made to authenticate the locked user")). I was thinking of adding a "manager.xml" file to $CATALINA_BASE/conf/[enginename]/[hostname]/ that will contain the following context container: Is this the correct way to achieve my goal of limiting access to the manager app to only my IP. Of course, I do not want the rest of my webapp's access limited (which is on the ROOT path). I only want access to the manager app limited. (I know I can also place the context container in my webapp's META-INF/context.xml file, is there any preference to doing this over what I suggested above?) Thank you _
Re: Linux Logging Rotate
Thanks Christopher, that's informative.
I've decided to just manually move (via ftp) the dated files off the server
and just clear Catalina.out (like your link says, the only unique output it
includes is system.out/err).
Eventually I will implement a more thorough logging solution.
Let me know if you have any suggestions for something simple.
Thanks.
On Friday, 20 May 2016, Christopher Schultz
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 5/18/16 7:41 AM, Yuval Schwartz wrote:
> > Hello,
> >
> > I am currently running a web application:
> >
> > Tomcat: 8.0.22 JDK: 1.8.0_05 Server: Amazon Linux AMI
> >
> > At the moment, I am simply using the default logging. catalina.out
> > catalina.[date].log localhost.[date].log host-manager.[date].log
> > localhost_access_log.[date].log manager.[date].log
> >
> > These log files build up in my {catalina.base}/logs directory.
> >
> > At the moment it's not a problem but eventually I would like to
> > clear these log files and store them somewhere (maybe send them to
> > my email).
> >
> > Does anyone have any solutions for what to do with these log
> > files? I looked into rotating them with logrotate but I read in a
> > few places that tomcat automatically rotates its log files and that
> > I shouldn't override this.
> >
> > I will eventually probably implement more thorough logging for my
> > application. But for the meantime, what should I do so that I don't
> > have a ton of log files in my logs directory? Any way to
> > automatically delete and email all log files with dates older than
> > one month? Should I implement logrotate on catalina.out since this
> > does not get dated?
> >
> > Thank you
>
> Does this help?
> http://wiki.apache.org/tomcat/HowTo#How_do_I_rotate_catalina.out.3F
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlc+OQkACgkQ9CaO5/Lv0PBsAACgpWGeCwhSkiTa7m8MYC7KMCae
> N6EAn3moj/uRXdDHNfG9a1w/3/ypB7O4
> =y7BX
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
Linux Logging Rotate
Hello,
I am currently running a web application:
Tomcat: 8.0.22
JDK: 1.8.0_05
Server: Amazon Linux AMI
At the moment, I am simply using the default logging.
catalina.out
catalina.[date].log
localhost.[date].log
host-manager.[date].log
localhost_access_log.[date].log
manager.[date].log
These log files build up in my {catalina.base}/logs directory.
At the moment it's not a problem but eventually I would like to clear these
log files and store them somewhere (maybe send them to my email).
Does anyone have any solutions for what to do with these log files?
I looked into rotating them with logrotate but I read in a few places that
tomcat automatically rotates its log files and that I shouldn't override
this.
I will eventually probably implement more thorough logging for my
application.
But for the meantime, what should I do so that I don't have a ton of log
files in my logs directory?
Any way to automatically delete and email all log files with dates older
than one month?
Should I implement logrotate on catalina.out since this does not get dated?
Thank you
Re: Mapping servlet to non English url pattern
Christopher,
On Wed, Mar 9, 2016 at 5:38 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Yuval,
>
> On 3/8/16 4:04 PM, Yuval Schwartz wrote:
> > @WebServlet(name="SomeServlet", urlPatterns={"/help/why-no-work",
> > "/iw/help/למה-לא-עובד",
> > "/iw/help/%D7%9C%D7%9E%D7%94-%D7%9C%D7%90-%D7%A2%D7%95%D7%91%D7%93"}
> > (the last pattern is the same as the second to last, just encoded)
>
> I think that last pattern will not be useful, because Tomcat should be
> doing the encoding internally. For example, if you wanted to map a
> servlet to "/foo bar" you wouldn't have to URL-encode it like /foo%20bar
> in the XML file. But I haven't actually tried it.
>
> (from your other post):
>
> On 3/8/16 5:35 PM, Yuval Schwartz wrote:
> > I did this and it worked:
> > The english patterns show up fine, as expected.
> > The hebrew pattern shows up as a bunch of question marks (eg:
> > -?-)
> > The URLEncoded pattern shows up as wierd symbols (eg: diamond shape,
> > tm symbol).
>
> Hmm, that could certainly be a problem with the tool itself (Netbeans?).
> Can you try running with jconsole just to have a (potentially) clean
> environment?
>
> The encoded pattern showing up as weird symbols sounds .. odd as well.
> Actually, everything about this sounds weird.
>
Do you say this because this is usually something that is straightforward
and simple that doesn't have many issues?
>
> On 3/9/16 4:38 AM, Yuval Schwartz wrote:
> > Are you suggesting I convert all of my source files to UTF-8? Will
> > all new files that are created now be in UTF-8 at least? Because I
> > just created a new servlet for testing purposes (after the
> > -J-Dfile.encoding property was added) and hebrew urls still aren't
> > found.
>
> You definitely don't need to convert your files to UTF-8, but you might
> instead want to use the encoding-proof Unicode escapes instead of the
> raw Hebrew in your source files.
>
> You can use native2ascii to do this for you:
>
> input.txt
> /iw/help/למה-לא-עובד
>
> $ native2ascii -encoding utf8 input.txt
> /iw/help/\u05dc\u05de\u05d4-\u05dc\u05d0-\u05e2\u05d5\u05d1\u05d3
>
> So those are the \u Unicode escapes that you should use in your code.
> Try using those and rebuilding to see if it improves anything.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Mapping servlet to non English url pattern
On Wed, Mar 9, 2016 at 7:46 PM, Mark Eggers wrote: > Yuval, > > Notes are inline (I hope). This is quickly becoming a NetBeans question. > > On 3/9/2016 1:38 AM, Yuval Schwartz wrote: > > Thanks Mark, follow up questions below: > > > > On Wed, Mar 9, 2016 at 1:26 AM, Mark Eggers > > > wrote: > > > >> Yuval, > >> > >> On 3/8/2016 2:35 PM, Yuval Schwartz wrote: > >>> On Tue, Mar 8, 2016 at 10:53 PM, Mark Thomas wrote: > >>> > >>>> On 08/03/2016 20:20, Christopher Schultz wrote: > >>>>> Yuval, > >>>>> > >>>>> On 3/8/16 12:38 PM, Yuval Schwartz wrote: > >>>>>> Hello Christopher, thanks, responses below. > >>>>> > >>>>>> On Tue, Mar 8, 2016 at 6:23 PM, Christopher Schultz < > >>>>>> ch...@christopherschultz.net> wrote: > >>>>> > >>>>>> Yuval, > >>>>> > >>>>>> On 3/8/16 3:14 AM, Yuval Schwartz wrote: > >>>>>>>>> Tomcat version: 8.0.22 Jdk: 1.8.0_05 Server: Amazon Linux > >>>>>>>>> > >>>>>>>>> Hello, > >>>>>>>>> > >>>>>>>>> I want to map my servlet to a Hebrew url pattern. > >>>>> > >>>>>> Hmm. > >>>>> > >>>>>>>>> I tried placing the hebrew url pattern both in the > >>>>>>>>> "@webservlet" annotation (urlpatterns attribute) and in the > >>>>>>>>> the web.xml file. In both cases it doesn't work, it's as if > >>>>>>>>> there's nothing mapped to the url specified. > >>>>>>>>> > >>>>>>>>> I though to specify the URIEncoding parameter of the > >>>>>>>>> connector but saw that this defaults to "utf-8" in tomcat 8. > >>>>> > >>>>>> Yes, it does. > >>>>> > >>>>>> So you are trying to set the url-pattern for a servlet mapping? > >>>>> > >>>>>> When you do it -- either using @WebServlet or -- > >>>>>> can you connect via JMX to observe the pattern that's been read > >>>>>> into the configuration? First, I'd want to make sure that the > >>>>>> Hebrew characters haven't been destroyed by the loading process of > >>>>>> the XML file or by the compiler, or even by Tomcat. > >>>>> > >>>>> > >>>>>>> Can you give me some direction on how I would do this? Maybe a > >>>>>>> little more detail on jmx? There could be encoding/decoding going > >>>>>>> on in the browser (firefox) and in all the elements you mentioned > >>>>>>> on the server side. Any way to see the final String that the > >>>>>>> server is using to match the Url pattern? > >>>>> > >>>>> Yeah, that's why I was suggesting using JMX, since Tomcat exposes all > >>>>> the configuration through it. > >>>>> > >>>>> Launch Tomcat, then fire-up jconsole (or VisualVM, or any other tool > >>>>> that contains a JMX client... both jconsole and VisualVM require that > >>>>> you go to the "plug-ins" configuration and install an > >>>>> easy-to-find-and-install plug-in for JMX) on the same machine (it's > >>>>> easiest this way). > >>>>> > >>>>> (I just checked, and VisualVM calls the plug-in > >>>>> "VisualVM-MBeans".)visualvisual > >>>>> > >>>>> Then, connect to the Tomcat instance and go to the BMeans tab. > >>>>> > >>>>> You'll find your servlet under > >> /Catalina/Servlet/host/context/[servlet]. > >>>>> .. > >>>>> > >>>>> > >>>>> Aw, crap. The mappings themselves aren't actually published via JMX. > >> Hmm > >>>> > >>>> Yes they are. > >>>> > >>>> You need to look at the operations. findMappings() will list them. > >>>> > >>> > >>> I did this and it worked: > >>> The english patterns show up fine, as expected. >
Re: Mapping servlet to non English url pattern
On Wed, Mar 9, 2016 at 5:38 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Yuval,
>
> On 3/8/16 4:04 PM, Yuval Schwartz wrote:
> > @WebServlet(name="SomeServlet", urlPatterns={"/help/why-no-work",
> > "/iw/help/למה-לא-עובד",
> > "/iw/help/%D7%9C%D7%9E%D7%94-%D7%9C%D7%90-%D7%A2%D7%95%D7%91%D7%93"}
> > (the last pattern is the same as the second to last, just encoded)
>
> I think that last pattern will not be useful, because Tomcat should be
> doing the encoding internally. For example, if you wanted to map a
> servlet to "/foo bar" you wouldn't have to URL-encode it like /foo%20bar
> in the XML file. But I haven't actually tried it.
>
> (from your other post):
>
> On 3/8/16 5:35 PM, Yuval Schwartz wrote:
> > I did this and it worked:
> > The english patterns show up fine, as expected.
> > The hebrew pattern shows up as a bunch of question marks (eg:
> > -?-)
> > The URLEncoded pattern shows up as wierd symbols (eg: diamond shape,
> > tm symbol).
>
> Hmm, that could certainly be a problem with the tool itself (Netbeans?).
> Can you try running with jconsole just to have a (potentially) clean
> environment?
>
Hey, can you clarify a bit? What do you mean "try running with jconsole"?
Run what? As I understand it, JConsole is for monitoring.
>
> The encoded pattern showing up as weird symbols sounds .. odd as well.
> Actually, everything about this sounds weird.
>
> On 3/9/16 4:38 AM, Yuval Schwartz wrote:
> > Are you suggesting I convert all of my source files to UTF-8? Will
> > all new files that are created now be in UTF-8 at least? Because I
> > just created a new servlet for testing purposes (after the
> > -J-Dfile.encoding property was added) and hebrew urls still aren't
> > found.
>
> You definitely don't need to convert your files to UTF-8, but you might
> instead want to use the encoding-proof Unicode escapes instead of the
> raw Hebrew in your source files.
>
> You can use native2ascii to do this for you:
>
> input.txt
> /iw/help/למה-לא-עובד
>
> $ native2ascii -encoding utf8 input.txt
> /iw/help/\u05dc\u05de\u05d4-\u05dc\u05d0-\u05e2\u05d5\u05d1\u05d3
>
> So those are the \u Unicode escapes that you should use in your code.
> Try using those and rebuilding to see if it improves anything.
>
This doesn't work.
>
> -chris
>
Thank you
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Mapping servlet to non English url pattern
Thanks Mark, follow up questions below: On Wed, Mar 9, 2016 at 1:26 AM, Mark Eggers wrote: > Yuval, > > On 3/8/2016 2:35 PM, Yuval Schwartz wrote: > > On Tue, Mar 8, 2016 at 10:53 PM, Mark Thomas wrote: > > > >> On 08/03/2016 20:20, Christopher Schultz wrote: > >>> Yuval, > >>> > >>> On 3/8/16 12:38 PM, Yuval Schwartz wrote: > >>>> Hello Christopher, thanks, responses below. > >>> > >>>> On Tue, Mar 8, 2016 at 6:23 PM, Christopher Schultz < > >>>> ch...@christopherschultz.net> wrote: > >>> > >>>> Yuval, > >>> > >>>> On 3/8/16 3:14 AM, Yuval Schwartz wrote: > >>>>>>> Tomcat version: 8.0.22 Jdk: 1.8.0_05 Server: Amazon Linux > >>>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> I want to map my servlet to a Hebrew url pattern. > >>> > >>>> Hmm. > >>> > >>>>>>> I tried placing the hebrew url pattern both in the > >>>>>>> "@webservlet" annotation (urlpatterns attribute) and in the > >>>>>>> the web.xml file. In both cases it doesn't work, it's as if > >>>>>>> there's nothing mapped to the url specified. > >>>>>>> > >>>>>>> I though to specify the URIEncoding parameter of the > >>>>>>> connector but saw that this defaults to "utf-8" in tomcat 8. > >>> > >>>> Yes, it does. > >>> > >>>> So you are trying to set the url-pattern for a servlet mapping? > >>> > >>>> When you do it -- either using @WebServlet or -- > >>>> can you connect via JMX to observe the pattern that's been read > >>>> into the configuration? First, I'd want to make sure that the > >>>> Hebrew characters haven't been destroyed by the loading process of > >>>> the XML file or by the compiler, or even by Tomcat. > >>> > >>> > >>>>> Can you give me some direction on how I would do this? Maybe a > >>>>> little more detail on jmx? There could be encoding/decoding going > >>>>> on in the browser (firefox) and in all the elements you mentioned > >>>>> on the server side. Any way to see the final String that the > >>>>> server is using to match the Url pattern? > >>> > >>> Yeah, that's why I was suggesting using JMX, since Tomcat exposes all > >>> the configuration through it. > >>> > >>> Launch Tomcat, then fire-up jconsole (or VisualVM, or any other tool > >>> that contains a JMX client... both jconsole and VisualVM require that > >>> you go to the "plug-ins" configuration and install an > >>> easy-to-find-and-install plug-in for JMX) on the same machine (it's > >>> easiest this way). > >>> > >>> (I just checked, and VisualVM calls the plug-in > >>> "VisualVM-MBeans".)visualvisual > >>> > >>> Then, connect to the Tomcat instance and go to the BMeans tab. > >>> > >>> You'll find your servlet under > /Catalina/Servlet/host/context/[servlet]. > >>> .. > >>> > >>> > >>> Aw, crap. The mappings themselves aren't actually published via JMX. > Hmm > >> > >> Yes they are. > >> > >> You need to look at the operations. findMappings() will list them. > >> > > > > I did this and it worked: > > The english patterns show up fine, as expected. > > The hebrew pattern shows up as a bunch of question marks (eg: > > -?-) > > The URLEncoded pattern shows up as wierd symbols (eg: diamond shape, tm > > symbol). > > > > Could this be something in my IDE (Netbeans) settings? The logs for > > example, display hebrew characters as question marks. Although my project > > encoding is set as UTF-8. > > > > Thanks. > > > > > > > >> > >> Mark > > Are you developing on Windows? (ah, you are) > > If so, could you check how you launch NetBeans? My netbeans.conf file > contains this on the netbeans_default_options line: > > -J-Dfile.encoding=UTF-8 > I tried this, still doesn't fix the issue (Although a change is noticed: going to help-->about under "system" text changes from "cp1252" to "UTF-8"). > > Also, if you're using Maven with NetBeans, UTF-8 has to be set there as > well. My projects contain the following in pom.xml: > > > UTF-8 > > > I don't think I use Maven for this. I use the default build process (for my development environment) ie: I right click the project and click "run". For my production I build with "gulp". > > If you have cygwin installed on Windows, you can use the following: > > file -bi [filename] > Which file am I supposed to do this for? > > will tell you the encoding and mime-type. > > iconv will help you convert from us-ascii to UTF-8. The syntax is: > > iconv -f [from-encoding] -t [to-encoding] [input-file] > output-file > Are you suggesting I convert all of my source files to UTF-8? Will all new files that are created now be in UTF-8 at least? Because I just created a new servlet for testing purposes (after the -J-Dfile.encoding property was added) and hebrew urls still aren't found. > > I suspect there are native Windows tools to do this, but I'd have to > wander about and find them. > > Notepad will tell you when you open a file what encoding the file is. > You could then do a "save as" and select the correct encoding. > > Sadly, NetBeans does not have a plugin to do this. > > . . . just my two cents > Thanks. > /mde/ > >
Re: Mapping servlet to non English url pattern
Sorry, I should also say, I specified in the beginning that I am using Amazon linux AMI but that is my production server. Right now, I'm testing in my development environment and this is on a windows system. All the rest of the versions I mentioned are the same. Could it be something with the Windows system that is not handling utf8 correctly? On Wed, Mar 9, 2016 at 12:35 AM, Yuval Schwartz wrote: > > > On Tue, Mar 8, 2016 at 10:53 PM, Mark Thomas wrote: > >> On 08/03/2016 20:20, Christopher Schultz wrote: >> > Yuval, >> > >> > On 3/8/16 12:38 PM, Yuval Schwartz wrote: >> >> Hello Christopher, thanks, responses below. >> > >> >> On Tue, Mar 8, 2016 at 6:23 PM, Christopher Schultz < >> >> ch...@christopherschultz.net> wrote: >> > >> >> Yuval, >> > >> >> On 3/8/16 3:14 AM, Yuval Schwartz wrote: >> >>>>> Tomcat version: 8.0.22 Jdk: 1.8.0_05 Server: Amazon Linux >> >>>>> >> >>>>> Hello, >> >>>>> >> >>>>> I want to map my servlet to a Hebrew url pattern. >> > >> >> Hmm. >> > >> >>>>> I tried placing the hebrew url pattern both in the >> >>>>> "@webservlet" annotation (urlpatterns attribute) and in the >> >>>>> the web.xml file. In both cases it doesn't work, it's as if >> >>>>> there's nothing mapped to the url specified. >> >>>>> >> >>>>> I though to specify the URIEncoding parameter of the >> >>>>> connector but saw that this defaults to "utf-8" in tomcat 8. >> > >> >> Yes, it does. >> > >> >> So you are trying to set the url-pattern for a servlet mapping? >> > >> >> When you do it -- either using @WebServlet or -- >> >> can you connect via JMX to observe the pattern that's been read >> >> into the configuration? First, I'd want to make sure that the >> >> Hebrew characters haven't been destroyed by the loading process of >> >> the XML file or by the compiler, or even by Tomcat. >> > >> > >> >>> Can you give me some direction on how I would do this? Maybe a >> >>> little more detail on jmx? There could be encoding/decoding going >> >>> on in the browser (firefox) and in all the elements you mentioned >> >>> on the server side. Any way to see the final String that the >> >>> server is using to match the Url pattern? >> > >> > Yeah, that's why I was suggesting using JMX, since Tomcat exposes all >> > the configuration through it. >> > >> > Launch Tomcat, then fire-up jconsole (or VisualVM, or any other tool >> > that contains a JMX client... both jconsole and VisualVM require that >> > you go to the "plug-ins" configuration and install an >> > easy-to-find-and-install plug-in for JMX) on the same machine (it's >> > easiest this way). >> > >> > (I just checked, and VisualVM calls the plug-in >> > "VisualVM-MBeans".)visualvisual >> > >> > Then, connect to the Tomcat instance and go to the BMeans tab. >> > >> > You'll find your servlet under /Catalina/Servlet/host/context/[servlet]. >> > .. >> > >> > >> > Aw, crap. The mappings themselves aren't actually published via JMX. Hmm >> >> Yes they are. >> >> You need to look at the operations. findMappings() will list them. >> > > I did this and it worked: > The english patterns show up fine, as expected. > The hebrew pattern shows up as a bunch of question marks (eg: > -?-) > The URLEncoded pattern shows up as wierd symbols (eg: diamond shape, tm > symbol). > > Could this be something in my IDE (Netbeans) settings? The logs for > example, display hebrew characters as question marks. Although my project > encoding is set as UTF-8. > > Thanks. > > > >> >> Mark >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
Re: Mapping servlet to non English url pattern
On Tue, Mar 8, 2016 at 10:53 PM, Mark Thomas wrote: > On 08/03/2016 20:20, Christopher Schultz wrote: > > Yuval, > > > > On 3/8/16 12:38 PM, Yuval Schwartz wrote: > >> Hello Christopher, thanks, responses below. > > > >> On Tue, Mar 8, 2016 at 6:23 PM, Christopher Schultz < > >> ch...@christopherschultz.net> wrote: > > > >> Yuval, > > > >> On 3/8/16 3:14 AM, Yuval Schwartz wrote: > >>>>> Tomcat version: 8.0.22 Jdk: 1.8.0_05 Server: Amazon Linux > >>>>> > >>>>> Hello, > >>>>> > >>>>> I want to map my servlet to a Hebrew url pattern. > > > >> Hmm. > > > >>>>> I tried placing the hebrew url pattern both in the > >>>>> "@webservlet" annotation (urlpatterns attribute) and in the > >>>>> the web.xml file. In both cases it doesn't work, it's as if > >>>>> there's nothing mapped to the url specified. > >>>>> > >>>>> I though to specify the URIEncoding parameter of the > >>>>> connector but saw that this defaults to "utf-8" in tomcat 8. > > > >> Yes, it does. > > > >> So you are trying to set the url-pattern for a servlet mapping? > > > >> When you do it -- either using @WebServlet or -- > >> can you connect via JMX to observe the pattern that's been read > >> into the configuration? First, I'd want to make sure that the > >> Hebrew characters haven't been destroyed by the loading process of > >> the XML file or by the compiler, or even by Tomcat. > > > > > >>> Can you give me some direction on how I would do this? Maybe a > >>> little more detail on jmx? There could be encoding/decoding going > >>> on in the browser (firefox) and in all the elements you mentioned > >>> on the server side. Any way to see the final String that the > >>> server is using to match the Url pattern? > > > > Yeah, that's why I was suggesting using JMX, since Tomcat exposes all > > the configuration through it. > > > > Launch Tomcat, then fire-up jconsole (or VisualVM, or any other tool > > that contains a JMX client... both jconsole and VisualVM require that > > you go to the "plug-ins" configuration and install an > > easy-to-find-and-install plug-in for JMX) on the same machine (it's > > easiest this way). > > > > (I just checked, and VisualVM calls the plug-in > > "VisualVM-MBeans".)visualvisual > > > > Then, connect to the Tomcat instance and go to the BMeans tab. > > > > You'll find your servlet under /Catalina/Servlet/host/context/[servlet]. > > .. > > > > > > Aw, crap. The mappings themselves aren't actually published via JMX. Hmm > > Yes they are. > > You need to look at the operations. findMappings() will list them. > I did this and it worked: The english patterns show up fine, as expected. The hebrew pattern shows up as a bunch of question marks (eg: -?-) The URLEncoded pattern shows up as wierd symbols (eg: diamond shape, tm symbol). Could this be something in my IDE (Netbeans) settings? The logs for example, display hebrew characters as question marks. Although my project encoding is set as UTF-8. Thanks. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Mapping servlet to non English url pattern
On Tue, Mar 8, 2016 at 10:55 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Yuval,
>
> On 3/8/16 3:47 PM, Yuval Schwartz wrote:
> > On Tue, Mar 8, 2016 at 10:20 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Yuval,
> >
> > On 3/8/16 12:38 PM, Yuval Schwartz wrote:
> >>>> Hello Christopher, thanks, responses below.
> >>>>
> >>>> On Tue, Mar 8, 2016 at 6:23 PM, Christopher Schultz <
> >>>> ch...@christopherschultz.net> wrote:
> >>>>
> >>>> Yuval,
> >>>>
> >>>> On 3/8/16 3:14 AM, Yuval Schwartz wrote:
> >>>>>>> Tomcat version: 8.0.22 Jdk: 1.8.0_05 Server: Amazon
> >>>>>>> Linux
> >>>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> I want to map my servlet to a Hebrew url pattern.
> >>>>
> >>>> Hmm.
> >>>>
> >>>>>>> I tried placing the hebrew url pattern both in the
> >>>>>>> "@webservlet" annotation (urlpatterns attribute) and in
> >>>>>>> the the web.xml file. In both cases it doesn't work,
> >>>>>>> it's as if there's nothing mapped to the url
> >>>>>>> specified.
> >>>>>>>
> >>>>>>> I though to specify the URIEncoding parameter of the
> >>>>>>> connector but saw that this defaults to "utf-8" in
> >>>>>>> tomcat 8.
> >>>>
> >>>> Yes, it does.
> >>>>
> >>>> So you are trying to set the url-pattern for a servlet
> >>>> mapping?
> >>>>
> >>>> When you do it -- either using @WebServlet or
> >>>> -- can you connect via JMX to observe the
> >>>> pattern that's been read into the configuration? First, I'd
> >>>> want to make sure that the Hebrew characters haven't been
> >>>> destroyed by the loading process of the XML file or by the
> >>>> compiler, or even by Tomcat.
> >>>>
> >>>>
> >>>>> Can you give me some direction on how I would do this?
> >>>>> Maybe a little more detail on jmx? There could be
> >>>>> encoding/decoding going on in the browser (firefox) and in
> >>>>> all the elements you mentioned on the server side. Any way
> >>>>> to see the final String that the server is using to match
> >>>>> the Url pattern?
> >
> > Yeah, that's why I was suggesting using JMX, since Tomcat exposes
> > all the configuration through it.
> >
> > Launch Tomcat, then fire-up jconsole (or VisualVM, or any other
> > tool that contains a JMX client... both jconsole and VisualVM
> > require that you go to the "plug-ins" configuration and install an
> > easy-to-find-and-install plug-in for JMX) on the same machine
> > (it's easiest this way).
> >
> > (I just checked, and VisualVM calls the plug-in
> > "VisualVM-MBeans".)visualvisual
> >
> > Then, connect to the Tomcat instance and go to the BMeans tab.
> >
> > You'll find your servlet under
> > /Catalina/Servlet/host/context/[servlet]. ..
> >
> >
> > Aw, crap. The mappings themselves aren't actually published via
> > JMX. Hmm .
> >
> >>>>> I've done a lot of guessing and checking. For example, I
> >>>>> used the URLEncoder to get the encoded form of my urls and
> >>>>> put that in the url pattern.
> >
> > Good. So you have some set of Unicode escapes like \u0fe64 or
> > whatever in the url-pattern string in your annotation?
> >
> >
> >> No, I don't have any unicode escapes. I have (for the purpose of
> >> testing) two strings, one is the string with the utf-8
> >> characters, the other is an encoded form of the url (which is
> >> encoded into a series of "%" followed by two English letters). Do
> >> you recommend having something else here?
>
> Can you copy/paste your @WebServlet annotation into your next post? I
> think that will clear things up.
>
@WebServlet(name="SomeServlet", urlPatterns={"/help/why-no-work",
"/iw/help/למה-לא-עובד",
"/iw/help/%D7%9C%D7%9E%D7%94-%D7%9C%D7
Re: Mapping servlet to non English url pattern
Thanks again, see below... On Tue, Mar 8, 2016 at 10:20 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Yuval, > > On 3/8/16 12:38 PM, Yuval Schwartz wrote: > > Hello Christopher, thanks, responses below. > > > > On Tue, Mar 8, 2016 at 6:23 PM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > Yuval, > > > > On 3/8/16 3:14 AM, Yuval Schwartz wrote: > >>>> Tomcat version: 8.0.22 Jdk: 1.8.0_05 Server: Amazon Linux > >>>> > >>>> Hello, > >>>> > >>>> I want to map my servlet to a Hebrew url pattern. > > > > Hmm. > > > >>>> I tried placing the hebrew url pattern both in the > >>>> "@webservlet" annotation (urlpatterns attribute) and in the > >>>> the web.xml file. In both cases it doesn't work, it's as if > >>>> there's nothing mapped to the url specified. > >>>> > >>>> I though to specify the URIEncoding parameter of the > >>>> connector but saw that this defaults to "utf-8" in tomcat 8. > > > > Yes, it does. > > > > So you are trying to set the url-pattern for a servlet mapping? > > > > When you do it -- either using @WebServlet or -- > > can you connect via JMX to observe the pattern that's been read > > into the configuration? First, I'd want to make sure that the > > Hebrew characters haven't been destroyed by the loading process of > > the XML file or by the compiler, or even by Tomcat. > > > > > >> Can you give me some direction on how I would do this? Maybe a > >> little more detail on jmx? There could be encoding/decoding going > >> on in the browser (firefox) and in all the elements you mentioned > >> on the server side. Any way to see the final String that the > >> server is using to match the Url pattern? > > Yeah, that's why I was suggesting using JMX, since Tomcat exposes all > the configuration through it. > > Launch Tomcat, then fire-up jconsole (or VisualVM, or any other tool > that contains a JMX client... both jconsole and VisualVM require that > you go to the "plug-ins" configuration and install an > easy-to-find-and-install plug-in for JMX) on the same machine (it's > easiest this way). > > (I just checked, and VisualVM calls the plug-in > "VisualVM-MBeans".)visualvisual > > Then, connect to the Tomcat instance and go to the BMeans tab. > > You'll find your servlet under /Catalina/Servlet/host/context/[servlet]. > .. > > > Aw, crap. The mappings themselves aren't actually published via JMX. Hmm > . > > >> I've done a lot of guessing and checking. For example, I used > >> the URLEncoder to get the encoded form of my urls and put that in > >> the url pattern. > > Good. So you have some set of Unicode escapes like \u0fe64 or whatever > in the url-pattern string in your annotation? > No, I don't have any unicode escapes. I have (for the purpose of testing) two strings, one is the string with the utf-8 characters, the other is an encoded form of the url (which is encoded into a series of "%" followed by two English letters). Do you recommend having something else here? Some more info: I placed a filter on pattern "/*". When my request with the UTF-8 url comes in, I call httpRequest.getServletPath() and httpRequest.getRequestURI(). As expected, I get the UTF-8 version of the servlet path (ie: decoded) and the ASCII request URI (ie: encoded) respectively. This means that the request is reaching my server. It's the next step, the step where the servlet path is mapped to my specified url pattern, that I want to explore. But I don't know how to explore this. Where can I control how the url pattern is matched with the incoming url? Although I can only conceive two options for how the incoming url is matched with the url pattern and I've tried both (either the UTF-8 version of the request url is matched against the pattern or the encoded version is matched against the pattern). > > >> Therefore, the xml loading process/compiler/tomcat/netbeans > >> shouldn't do anything to change it (in the case where I encode > >> the pattern), but the servlet still isn't found. > > Well, if you use annotations, the XML shouldn't be a problem at all, > of course. But you said you were having problems using the > web.xml-based configuration, too, right? > > When you type the URL into your browser, are you just typing the > Hebrew right
Re: Mapping servlet to non English url pattern
Hello Christopher, thanks, responses below. On Tue, Mar 8, 2016 at 6:23 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Yuval, > > On 3/8/16 3:14 AM, Yuval Schwartz wrote: > > Tomcat version: 8.0.22 Jdk: 1.8.0_05 Server: Amazon Linux > > > > Hello, > > > > I want to map my servlet to a Hebrew url pattern. > > Hmm. > > > I tried placing the hebrew url pattern both in the "@webservlet" > > annotation (urlpatterns attribute) and in the the web.xml file. In > > both cases it doesn't work, it's as if there's nothing mapped to > > the url specified. > > > > I though to specify the URIEncoding parameter of the connector but > > saw that this defaults to "utf-8" in tomcat 8. > > Yes, it does. > > So you are trying to set the url-pattern for a servlet mapping? > > When you do it -- either using @WebServlet or -- can > you connect via JMX to observe the pattern that's been read into the > configuration? First, I'd want to make sure that the Hebrew characters > haven't been destroyed by the loading process of the XML file or by > the compiler, or even by Tomcat. > Can you give me some direction on how I would do this? Maybe a little more detail on jmx? There could be encoding/decoding going on in the browser (firefox) and in all the elements you mentioned on the server side. Any way to see the final String that the server is using to match the Url pattern? I've done a lot of guessing and checking. For example, I used the URLEncoder to get the encoded form of my urls and put that in the url pattern. Therefore, the xml loading process/compiler/tomcat/netbeans shouldn't do anything to change it (in the case where I encode the pattern), but the servlet still isn't found. Thanks. > Can you confirm that the browser is sending the URL without ruining it > as well? > > Tomcat's Mapper follows the spec-defined rules for mapping a URL to a > servlet, so it's possible that another servlet will take-over the > mapping, depending upon how it's defined. Remember, the spec says that > an exact-match wins, followed by a prefix-match (/foo/bar/baz/*) > (longest match wins), followed by an extension-match (*.img), followed > by things like welcome-file resources, etc. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlbe/IMACgkQ9CaO5/Lv0PCupACbBDmQYb9WmxM6R0F+FpKK6bB5 > /DMAnAv7tv6nYOcfQDXFl1NltegV47lA > =L+ec > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Mapping servlet to non English url pattern
Tomcat version: 8.0.22 Jdk: 1.8.0_05 Server: Amazon Linux Hello, I want to map my servlet to a Hebrew url pattern. I tried placing the hebrew url pattern both in the "@webservlet" annotation (urlpatterns attribute) and in the the web.xml file. In both cases it doesn't work, it's as if there's nothing mapped to the url specified. I though to specify the URIEncoding parameter of the connector but saw that this defaults to "utf-8" in tomcat 8. Any suggestions on how I can get this working? Thank you.
Re: ELB Creating Multiple Sessions with Every Ping
On Mon, Feb 8, 2016 at 6:53 PM, Peter Rifel wrote: > Yuval, > > > > On 2/8/16, 6:57 AM, "Christopher Schultz" > wrote: > > >-BEGIN PGP SIGNED MESSAGE- > >Hash: SHA1 > > > >Yuval, > > > >On 2/7/16 2:27 AM, Yuval Schwartz wrote: > >> tomcat version: 8.0.22 java: jdk1.8.0_05 server: amazon linux ami > >> > >> This might be outside the scope of this forum. I have an ELB > >> (Elastic Load Balancer) distributing load between two instances > >> that run tomcat. When I observe the tomcat manager app I see that > >> at every health check interval (1 per 60 seconds) the ELB is > >> creating 4 new sessions (ie: 4 different session ids are listed in > >> the "Sessions Adminstration" page per ping). Is this normal? Why > >> doesn't it just create 1 session per ping? > > > >Because the ELB doesn't maintain JSESSIONID cookies across pings. > > Also I've noticed in my Tomcat access logs that ELB health checks come > from two different IP addresses and each performs a check at the defined > interval, so you may see double the requests. > > Yes, thank you. I read somewhere that ELB's ping from each instance running the ELB (which is determined by load on the ELB), so it could fluctuate. I'll look into this as well as Christopher's answer. > Peter > > > > > > > >What you need to do is pick a different URL for the ELB to use to ping > >the backend instances: one that won't automatically create a new session > >. > > > >- -chris > >-BEGIN PGP SIGNATURE- > >Comment: GPGTools - http://gpgtools.org > >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > >iEYEARECAAYFAla4rOQACgkQ9CaO5/Lv0PDnuwCdFqdNo6cZJO26fj0zvLFsr1Bw > >48EAoLhRkEwSpB76yDIvBcEMNi8H/oqU > >=2R3W > >-END PGP SIGNATURE- > > > >- > >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >For additional commands, e-mail: users-h...@tomcat.apache.org > > >
ELB Creating Multiple Sessions with Every Ping
tomcat version: 8.0.22 java: jdk1.8.0_05 server: amazon linux ami This might be outside the scope of this forum. I have an ELB (Elastic Load Balancer) distributing load between two instances that run tomcat. When I observe the tomcat manager app I see that at every health check interval (1 per 60 seconds) the ELB is creating 4 new sessions (ie: 4 different session ids are listed in the "Sessions Adminstration" page per ping). Is this normal? Why doesn't it just create 1 session per ping? Thank you _
Re: Installing APR based Apache Tomcat Native Library
Thank you for all of your help, very informative. Regarding your last answer, I will look at it in greater detail and let you know if I have questions (I am less familiar with some of the term you mention there). On Fri, Feb 5, 2016 at 11:48 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Yuval, > > On 2/4/16 3:14 AM, Yuval Schwartz wrote: > >> On Wed, Feb 3, 2016 at 11:15 PM, Christopher Schultz < > >> ch...@christopherschultz.net> wrote: > > > > ELB usually uses HTTP keepalive, so that might be part of the > > issue. > > > >> ELB has a feature called "connection draining" which keeps > >> connections open while the instance is de-registering (my > >> instance begins de-registering when I shutdown tomcat) for a set > >> period of time (default: 300 s). It is this connection that stays > >> open when tomcat shuts down that causes the WARNING message to > >> appear. If I disable connection draining then I stop seeing the > >> WARNING when I shutdown tomcat. > > That'll do it. > > So, if you had waited 5 minutes between removing your node from ELB > and shutting-down Tomcat, you'd find that there also no errors. > > >> However, "connection draining" seems like a nice feature. One > >> option to overcome this WARNING while still keeping connection > >> draining would be to first undeploy my application, then, after > >> the connection draining time period expires, shutdown tomcat > >> (tested this, doesn't throw the warning). > > > >> Do you have any other recommendations for how I might keep this > >> feature and adjust something else in my configuration? Any light > >> to shed on the matter? > > Wait 5 minutes? > > 5 minutes is quite a long time to drain the node. How long is the > average request? In production, we use ELB with 30-second draining. > > (Then again, we have a layer of stateless httpd instances in > between... when we drain our Tomcat nodes, we typically wait over an > hour.) > > I think this might come down to the lack of flexibility of ELB. > > The way we use ELB, we are balancing between a set of httpd instances > which are *all* proxying to the same set of back-end Tomcat nodes. So > the currently-enabled set of httpd instances is irrelevant to the > client: any httpd can get to any Tomcat. > > When we want to service an httpd instance, we remove it from the ELB > with a short draining period and reboot, upgrade, whatever. No > interruption to the Tomcat nodes. > > If we want to service a Tomcat node, we bring-down the node from > *httpd*, not from ELB. We are using mod_jk which allows you to put a > Tomcat node into a "disabled" state, which means existing users will > still be routed to the node that is "going down" but new users will go > to other nodes instead. Once the number of sessions on that node goes > to zero, we STOP the node in mod_jk (NO TRAFFIC AT ALL to the node) > and then service it. > > ELB lacks this two-phase removal feature that mod_jk has. That means, > when you remove a node from ELB, the countdown starts for your > users... if they don't log off from that node, they will lose their > sessions in T minus 5 minutes. If you are using sticky sessions with > no clustering (like we are), then those users are just out of luck > when the 5-minute timer runs out. > > If you want better behavior, you are going to need more complexity. > > /On the other hand/, if you *are* clustered and don't use (or need) > sticky sessions, then you can significantly reduce that user-draining > period to the maximum reasonable response time you expect to be able > to serve. If you have a super-fast entirely-clustered (or stateless) > service, set the drain time to 1 second. If you have requests that > routinely last 45 seconds, set the drain-time to more like 90 seconds. > 5 minutes doesn't seem like it makes any sense to be in any scenario, > though. > > Hope that helps, > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAla1GMcACgkQ9CaO5/Lv0PBO+ACeJLP4z3DUfcUqVmG30w7sYSsN > 5ggAoLDU8DSnA1vjVppiN9QU11GFsfng > =RhN2 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Installing APR based Apache Tomcat Native Library
Update below. On Thu, Feb 4, 2016 at 8:15 AM, Yuval Schwartz wrote: > Thanks, answers below. > > On Wed, Feb 3, 2016 at 11:15 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Yuval, >> >> On 2/3/16 12:29 PM, Yuval Schwartz wrote: >> > Thanks a lot. Comments below. >> > >> > On Wed, Feb 3, 2016 at 5:02 PM, Christopher Schultz < >> > ch...@christopherschultz.net> wrote: >> > >> > Try this. Before you are ready to shut down, take note of the pid >> > of the JVM process. Then run this command: >> > >> > $ CATALINA_HOME/bin/shutdown.sh && sleep 2 && jstack [pid] > >> > stack.txt >> > >> > >> >> (Nice idea!) I performed this and it worked. What stood out was a >> >> line in 2 http-apr-8080 threads: - locked <[some number]> (a >> >> org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper) >> > >> >> Does this tell us something? >> >> Can you post the rest of the stack trace? >> > > Yes, sure: > > "http-apr-8080-exec-7" #32 daemon prio=5 os_prio=0 tid=0x7f118c015800 > nid=0x2d10 runnable [0x7f1192ef1000] >java.lang.Thread.State: RUNNABLE > at org.apache.tomcat.jni.Socket.recvbb(Native Method) > at > org.apache.coyote.http11.InternalAprInputBuffer.doReadSocket(InternalAprInputBuffer.java:631) > at > org.apache.coyote.http11.InternalAprInputBuffer.fill(InternalAprInputBuffer.java:583) > at > org.apache.coyote.http11.InternalAprInputBuffer.parseRequestLine(InternalAprInputBuffer.java:140) > at > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1005) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668) > at > org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:2400) > - locked <0xf12d0080> (a > org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:745) > > The thing is, I found an identical thread from a thread dump that I called > before the shutdown (ie: before the warning was thrown). Only it was named > "http-apr-8080-exec-6". > > >> >> > This should request a Tomcat shutdown and take a thread dump 2 >> > seconds later. If that doesn't work, adjust the sleep time until >> > you get a good snapshot. You should see a thread with a name like >> > http-apr-8080-[#] that is doing something inside your application. >> > then its up to you to figure out why it's still running. >> > >> > >> >> As far as I can tell, I only get this WARNING when my elastic >> >> load balancer is pinging pages on my web app. >> >> ELB usually uses HTTP keepalive, so that might be part of the issue. >> > ELB has a feature called "connection draining" which keeps connections open while the instance is de-registering (my instance begins de-registering when I shutdown tomcat) for a set period of time (default: 300 s). It is this connection that stays open when tomcat shuts down that causes the WARNING message to appear. If I disable connection draining then I stop seeing the WARNING when I shutdown tomcat. However, "connection draining" seems like a nice feature. One option to overcome this WARNING while still keeping connection draining would be to first undeploy my application, then, after the connection draining time period expires, shutdown tomcat (tested this, doesn't throw the warning). Do you have any other recommendations for how I might keep this feature and adjust something else in my configuration? Any light to shed on the matter? Thanks a lot. > >> > What is your connector configuration? >> > >> >> The connector element in $CATALINA_HOME/conf/server.xml looks >> >> like this: > >> connectionTimeout="2" redirectPort="8443" /> (there is a >> >> commented connector after it with an attribute of >> >> "executor=tomcatThreadPool"...but this is commented out). >> >> So that's pretty much the default configuration. Good to know. >> >> - -chris >> -BEGIN PGP SIGNATURE- >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iEYEARECAAYFAlaybdUACgkQ9CaO5/Lv0PCS7wCeMKCjgMLSrGAAj5lQUjGG5oza >> w34An2e7kYagW6zIN6tPTS7kXu/XcAf7 >> =eZ7k >> -END PGP SIGNATURE- >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
Re: Installing APR based Apache Tomcat Native Library
Thanks, answers below. On Wed, Feb 3, 2016 at 11:15 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Yuval, > > On 2/3/16 12:29 PM, Yuval Schwartz wrote: > > Thanks a lot. Comments below. > > > > On Wed, Feb 3, 2016 at 5:02 PM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > Try this. Before you are ready to shut down, take note of the pid > > of the JVM process. Then run this command: > > > > $ CATALINA_HOME/bin/shutdown.sh && sleep 2 && jstack [pid] > > > stack.txt > > > > > >> (Nice idea!) I performed this and it worked. What stood out was a > >> line in 2 http-apr-8080 threads: - locked <[some number]> (a > >> org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper) > > > >> Does this tell us something? > > Can you post the rest of the stack trace? > Yes, sure: "http-apr-8080-exec-7" #32 daemon prio=5 os_prio=0 tid=0x7f118c015800 nid=0x2d10 runnable [0x7f1192ef1000] java.lang.Thread.State: RUNNABLE at org.apache.tomcat.jni.Socket.recvbb(Native Method) at org.apache.coyote.http11.InternalAprInputBuffer.doReadSocket(InternalAprInputBuffer.java:631) at org.apache.coyote.http11.InternalAprInputBuffer.fill(InternalAprInputBuffer.java:583) at org.apache.coyote.http11.InternalAprInputBuffer.parseRequestLine(InternalAprInputBuffer.java:140) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1005) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668) at org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:2400) - locked <0xf12d0080> (a org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) The thing is, I found an identical thread from a thread dump that I called before the shutdown (ie: before the warning was thrown). Only it was named "http-apr-8080-exec-6". > > > This should request a Tomcat shutdown and take a thread dump 2 > > seconds later. If that doesn't work, adjust the sleep time until > > you get a good snapshot. You should see a thread with a name like > > http-apr-8080-[#] that is doing something inside your application. > > then its up to you to figure out why it's still running. > > > > > >> As far as I can tell, I only get this WARNING when my elastic > >> load balancer is pinging pages on my web app. > > ELB usually uses HTTP keepalive, so that might be part of the issue. > > > What is your connector configuration? > > > >> The connector element in $CATALINA_HOME/conf/server.xml looks > >> like this: >> connectionTimeout="2" redirectPort="8443" /> (there is a > >> commented connector after it with an attribute of > >> "executor=tomcatThreadPool"...but this is commented out). > > So that's pretty much the default configuration. Good to know. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlaybdUACgkQ9CaO5/Lv0PCS7wCeMKCjgMLSrGAAj5lQUjGG5oza > w34An2e7kYagW6zIN6tPTS7kXu/XcAf7 > =eZ7k > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Installing APR based Apache Tomcat Native Library
Thanks a lot. Comments below. On Wed, Feb 3, 2016 at 5:02 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Yuval, > > On 2/2/16 6:11 PM, Yuval Schwartz wrote: > > Thanks. Answers below > > > > On Tuesday, 2 February 2016, Christopher Schultz < > > ch...@christopherschultz.net > > > > > wrote: > > > > Yuval, > > > > On 2/2/16 9:28 AM, Yuval Schwartz wrote: > >>>> On Tue, Feb 2, 2016 at 4:15 PM, Christopher Schultz < > >>>> ch...@christopherschultz.net> wrote: > >>>> > >>>> Yuval, > >>>> > >>>> On 2/2/16 6:21 AM, Yuval Schwartz wrote: > >>>>>>> Hello again Christoph, > >>>>>>> > >>>>>>> I think there is a problem with the way that I > >>>>>>> installed the APR library. If you recall, I installed a > >>>>>>> compiled version from the distros with the commands yum > >>>>>>> install apr-devel openssl-devel tomcat-native > >>>>>>> > >>>>>>> I get the desired "Loaded APR based library" in my > >>>>>>> logs. However, every time I shut down tomcat I get a > >>>>>>> warning: > >>>>>>> > >>>>>>> WARNING [main] > >>>>>>> org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor > >>>>>>> > >>>>>>> > The executor associated with thread pool [http-apr-8080] has > >>>>>>> not fully shutdown. Some application threads may still > >>>>>>> be running > >>>>>>> > >>>>>>> If I remove the packages that I installed (yum remove > >>>>>>> apr-devel openssl-devel tomcat-native) then this > >>>>>>> warning goes away. > >>>>>>> > >>>>>>> Is there something that I forgot to configure when > >>>>>>> installing the APR library? > >>>> > >>>> What makes you think that something is wrong with the > >>>> library? Perhaps you are getting that WARNING because you > >>>> have still-running request-processing threads? > >>>> > >>>> > >>>>> Thanks, any ideas on how I can look into this then? I've > >>>>> tried looking at thread dumps and at the threads that are > >>>>> created and destroyed in my ServletContextListener's > >>>>> contextInitialize and contextDestroyed methods. > > > > So, just to confirm, when you attempt to shut-down Tomcat, you get > > that WARNING and if you take a thread dump after that warning, you > > have threads still running contextInitialized and > > contextDestroyed? > > > > > >> When I shut down I get that message (I am able to shut down > >> successfully, I just get that message right before). I can't take > >> a thread dump after I get the message because tomcat is no longer > >> running (i.e. There are no Java processes taking place for me to > >> perform a thread dump on). > > Try this. Before you are ready to shut down, take note of the pid of > the JVM process. Then run this command: > > $ CATALINA_HOME/bin/shutdown.sh && sleep 2 && jstack [pid] > stack.txt > (Nice idea!) I performed this and it worked. What stood out was a line in 2 http-apr-8080 threads: - locked <[some number]> (a org.apache.tomcat.util.net.AprEndpoint$AprSocketWrapper) Does this tell us something? > > This should request a Tomcat shutdown and take a thread dump 2 seconds > later. If that doesn't work, adjust the sleep time until you get a > good snapshot. You should see a thread with a name like > http-apr-8080-[#] that is doing something inside your application. > then its up to you to figure out why it's still running. > As far as I can tell, I only get this WARNING when my elastic load balancer is pinging pages on my web app. > > >> I mentioned contextInitialized and contextDestroyed simply > >> because I used those methods to print information about threads > >> that were running in order to try to get a better idea of what's > >> going on (i.e. Using Thread.getAllStackTraces()). > > Well, if you are using contextInitialized and contextDestroyed to dump > the stacks of all threads, then of course those methods
Installing APR based Apache Tomcat Native Library
Thanks. Answers below On Tuesday, 2 February 2016, Christopher Schultz < ch...@christopherschultz.net > wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Yuval, > > On 2/2/16 9:28 AM, Yuval Schwartz wrote: > > On Tue, Feb 2, 2016 at 4:15 PM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > Yuval, > > > > On 2/2/16 6:21 AM, Yuval Schwartz wrote: > >>>> Hello again Christoph, > >>>> > >>>> I think there is a problem with the way that I installed the > >>>> APR library. If you recall, I installed a compiled version > >>>> from the distros with the commands yum install apr-devel > >>>> openssl-devel tomcat-native > >>>> > >>>> I get the desired "Loaded APR based library" in my logs. > >>>> However, every time I shut down tomcat I get a warning: > >>>> > >>>> WARNING [main] > >>>> org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor > >>>> The executor associated with thread pool [http-apr-8080] has > >>>> not fully shutdown. Some application threads may still be > >>>> running > >>>> > >>>> If I remove the packages that I installed (yum remove > >>>> apr-devel openssl-devel tomcat-native) then this warning goes > >>>> away. > >>>> > >>>> Is there something that I forgot to configure when installing > >>>> the APR library? > > > > What makes you think that something is wrong with the library? > > Perhaps you are getting that WARNING because you have > > still-running request-processing threads? > > > > > >> Thanks, any ideas on how I can look into this then? I've tried > >> looking at thread dumps and at the threads that are created and > >> destroyed in my ServletContextListener's contextInitialize and > >> contextDestroyed methods. > > So, just to confirm, when you attempt to shut-down Tomcat, you get > that WARNING and if you take a thread dump after that warning, you > have threads still running contextInitialized and contextDestroyed? When I shut down I get that message (I am able to shut down successfully, I just get that message right before). I can't take a thread dump after I get the message because tomcat is no longer running (i.e. There are no Java processes taking place for me to perform a thread dump on). I mentioned contextInitialized and contextDestroyed simply because I used those methods to print information about threads that were running in order to try to get a better idea of what's going on (i.e. Using Thread.getAllStackTraces()). > > The thread the WARNING is talking about will be one of the HTTP > request processor threads (it even tells you which thread pool is > still in use: http-apr-8080). If you have some long-running requests, > you may get that WARNING during shutdown, but shutdown can still > succeed after those threads complete. > > When I take a thread dump while the application is running I see threads called http-apr-8080-exec-1, http-apr-8080-exec-2, etc. do these threads belong to the pool that the warning is referring to? Are you saying I don't need to pay attention to this warning? As a side question: why should it concern me that a thread might stay open when tomcat is shutting down? If tomcat is shutting down then won't all threads be destroyed anyway? > > If the library loads, I think you installed it properly ;) > > > > > >> Yes, I just reinstalled by compiling the source code and I still > >> get the same error...so it's not the library. > > If you are okay with the library version available from your Linux > distro, you should stick with that. I mentioned this point because, interestingly, when I don't use the apr library (i.e. I use the standard nio) then I don't see the warning that we're discussing. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlaxDPgACgkQ9CaO5/Lv0PAgbACeN/Pw1NF+f8Ak9HXeS27vlUKp > 8QAAnirgkqU04C9kTVixWDuDz0jZeBE5 > =hEat > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: WebAppClassLoaderBase.clearReferencesThreads warning
Hello Terence,
Can you explain what you mean when you say "who owns the thread"?
On Tue, Feb 2, 2016 at 5:18 PM, Terence M. Bandoian
wrote:
> On 2/2/2016 2:49 AM, Yuval Schwartz wrote:
>
>>
>>
>> On Mon, Feb 1, 2016 at 7:36 PM, Terence M. Bandoian > <mailto:tere...@tmbsw.com>> wrote:
>>
>> On 2/1/2016 10:12 AM, Yuval Schwartz wrote:
>>
>> Hello Terence,
>>
>> Thanks for the input.
>> I shutdown the ScheduledExecutorService in the
>> contextDestroyed method of
>> the app's ServletContextListener class as well.
>> I also call shutDownNow() followed by an if statement with
>> !awaitTermination() as the condition.
>>
>> Are you sure that the new warning that I'm getting is also
>> related to the
>> ScheduledExecutorService?
>> The warning again is:
>>
>> WARNING [main] org.apache.tomcat.util.net
>> <http://org.apache.tomcat.util.net
>> >.AbstractEndpoint.shutdownExecutor
>> The executor associated with thread pool [http-apr-8080] has
>> not fully
>> shutdown. Some application threads may still be running
>>
>> I didn't find much information about http-apr-8080 on google.
>> When I do a thread dump while tomcat is running I see
>> http-apr-8080-exec-1,
>> http-apr-8080-exec-2,...http-apr-8080-exec-10.
>> I'm not sure what these do? Are these threads the same as
>> http-apr-8080
>> that is referenced in the warning?
>>
>> How else can I go about debugging this message?
>>
>> Thank you
>>
>>
>>
>> Hi, Yuval-
>>
>> I'm not sure the new warning is related to the way the
>> ScheduledExecutorService is stopped. You mentioned though that
>> the previous warning was related so I thought I'd share my
>> experience. Here's the code I used:
>>
>> public void contextDestroyed( ServletContextEvent sce )
>> {
>> if ( executor != null )
>> {
>> boolean isTerminated = false;
>>
>> executor.shutdown();
>>
>> do
>> {
>> try
>> {
>> isTerminated = executor.awaitTermination(
>> 1, TimeUnit.SECONDS );
>> }
>> catch ( InterruptedException ignore )
>> {
>> }
>> }
>> while ( !isTerminated );
>>
>> executor = null;
>>
>> Thread.yield();
>>
>>
>> Java docs say use of this method is rarely necessary...so I'm a little
>> hesitant to use it.
>>
>> }
>> }
>>
>> Notice the loop.
>>
>> For the new warning, my suggestion would be to find out who owns
>> the thread in question. Can you do that with the profiler?
>>
>>
>> Thanks. I don't use a profiler. I'm using Jstack, and at the time the
>> application is running, when I do a thread dump, I don't see this thread
>> ("http-apr-8080").
>>
>> I also did some testing on my development environment and printing the
>> threads right before tomcat shuts down prints some threads, but again, none
>> are named "http-apr-8080" (although some are named http-apr-8080-exec-...).
>>
>>
>> Hope that helps.
>>
>> -Terence Bandoian
>>
>>
>>
>>
>> On Mon, Feb 1, 2016 at 5:59 PM, Terence M. Bandoian
>> mailto:tere...@tmbsw.com>>
>> wrote:
>>
>> On 2/1/2016 8:54 AM, Yuval Schwartz wrote:
>>
>> Hello Mark,
>>
>> I think that the issue below was related to the way I
>> was shutting down an
>> instance of ScheduledExecutorService.
>> I changed the way it is shutdown when the context is
>> destroyed...I will
>> update here if I don't receive any more warnings.
>>
>> However, I now get a warning:
>>
>> WARNING [main] org.apache.tomcat.util.net
>> <http://org.apache.tomcat.util.net>
>
Re: Installing APR based Apache Tomcat Native Library
On Tue, Feb 2, 2016 at 4:15 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Yuval, > > On 2/2/16 6:21 AM, Yuval Schwartz wrote: > > Hello again Christoph, > > > > I think there is a problem with the way that I installed the APR > > library. If you recall, I installed a compiled version from the > > distros with the commands yum install apr-devel openssl-devel > > tomcat-native > > > > I get the desired "Loaded APR based library" in my logs. However, > > every time I shut down tomcat I get a warning: > > > > WARNING [main] > > org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor The > > executor associated with thread pool [http-apr-8080] has not fully > > shutdown. Some application threads may still be running > > > > If I remove the packages that I installed (yum remove apr-devel > > openssl-devel tomcat-native) then this warning goes away. > > > > Is there something that I forgot to configure when installing the > > APR library? > > What makes you think that something is wrong with the library? Perhaps > you are getting that WARNING because you have still-running > request-processing threads? > Thanks, any ideas on how I can look into this then? I've tried looking at thread dumps and at the threads that are created and destroyed in my ServletContextListener's contextInitialize and contextDestroyed methods. > > If the library loads, I think you installed it properly ;) > Yes, I just reinstalled by compiling the source code and I still get the same error...so it's not the library. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlawuh8ACgkQ9CaO5/Lv0PAnhQCfcpg316jjclM41xnDjQtZrr9Z > I7UAoLw0jg8tPK6m51HQDyXbCQnb402r > =fZGU > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Installing APR based Apache Tomcat Native Library
Hello again Christoph, I think there is a problem with the way that I installed the APR library. If you recall, I installed a compiled version from the distros with the commands yum install apr-devel openssl-devel tomcat-native I get the desired "Loaded APR based library" in my logs. However, every time I shut down tomcat I get a warning: WARNING [main] org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor The executor associated with thread pool [http-apr-8080] has not fully shutdown. Some application threads may still be running If I remove the packages that I installed (yum remove apr-devel openssl-devel tomcat-native) then this warning goes away. Is there something that I forgot to configure when installing the APR library? Thank you _ On Thu, Jan 28, 2016 at 2:34 PM, Yuval Schwartz wrote: > Thank you Christoph, > > I installed a compiled version from the distros on my production servers > and I installed the binary version from > http://tomcat.apache.org/download-native.cgi > on my development server. > > A slight problem is that when I install from the distros I don't have > control of the version and therefore there is a slight mismatch between my > development and production environments (development version: Apache Tomcat > Native Library 1.1.34 using APR 1.5.1, production version: Apache Tomcat > Native Library 1.1.33 using APR 1.5.1) > > > Thank you > > On Thu, Jan 28, 2016 at 10:27 AM, Christoph Nenning < > christoph.nenn...@lex-com.net> wrote: > >> > Hello, >> > >> > tomcat version: 8.0.22 >> > java: jdk1.8.0_05 >> > server: Amazon Linux AMI >> > >> > When deploying my web application to my production environment (detailed >> > above), I get a message: >> > >> > >> > >> > *The APR based Apache Tomcat Native library which allows optimal >> > performance in production environments was not found on the >> > java.library.path* >> > So I wanted to install the Apache Tomcat Native library (does this >> improve >> > performance even for a web app that doesn't use SSL?) >> > According to the documentation: http://tomcat.apache.org/native-doc/ >> > I installed the apr-devel and openssl-devel packages with the command: >> > >> > yum install apr-devel openssl-devel >> > >> > However, I don't understand the next part of the instructions which >> > discusses the "make && make install" command. >> > From where do I run this command? I searched and I could not find a >> > "jni/native" directory. >> > From where do I run the "./configure --help" command and the other >> > "./configure" commands? >> > >> > Thank you. >> >> >> Those commands mean you compile source code of those libraries. So you >> have to either download source code as zip archives and extract them or >> check it out from version control. You probably need more C development >> tools like a compiler. >> >> >> Instead of compiling it yourself you can try to install a precompiled >> version from your linux disros repositories: >> >> yum install apr tomcat-native >> >> If you use a recent version of tomcat it might happen that precompiled >> libraries are outdated. >> >> If you just want to avoid that log message you can disable apr connector >> AprLifecycleListener in server.xml. >> >> >> >> Regards, >> Christoph >> >> This Email was scanned by Sophos Anti Virus >> > >
Re: WebAppClassLoaderBase.clearReferencesThreads warning
Hello Terence, Thanks for the input. I shutdown the ScheduledExecutorService in the contextDestroyed method of the app's ServletContextListener class as well. I also call shutDownNow() followed by an if statement with !awaitTermination() as the condition. Are you sure that the new warning that I'm getting is also related to the ScheduledExecutorService? The warning again is: WARNING [main] org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor The executor associated with thread pool [http-apr-8080] has not fully shutdown. Some application threads may still be running I didn't find much information about http-apr-8080 on google. When I do a thread dump while tomcat is running I see http-apr-8080-exec-1, http-apr-8080-exec-2,...http-apr-8080-exec-10. I'm not sure what these do? Are these threads the same as http-apr-8080 that is referenced in the warning? How else can I go about debugging this message? Thank you On Mon, Feb 1, 2016 at 5:59 PM, Terence M. Bandoian wrote: > On 2/1/2016 8:54 AM, Yuval Schwartz wrote: > >> Hello Mark, >> >> I think that the issue below was related to the way I was shutting down an >> instance of ScheduledExecutorService. >> I changed the way it is shutdown when the context is destroyed...I will >> update here if I don't receive any more warnings. >> >> However, I now get a warning: >> >> WARNING [main] org.apache.tomcat.util.net >> .AbstractEndpoint.shutdownExecutor >> The executor associated with thread pool [http-apr-8080] has not fully >> shutdown. Some application threads may still be running >> >> I am not sure if this is related or not? >> When I do a heap dump with jstack I see http-apr-8080-exec-[1-10] but I >> don't see any thread named http-apr-8080. >> Any ideas on how to trouble shoot this? >> >> Thanks. >> > > > Hi, Yuval- > > Where are you shutting down the ScheduledExecutorService? I ran into a > similar problem trying to stop a ScheduledExecutorService in the > contextDestroyed method of a ServletContextListener. Adding a call to > Thread.yield() after the executor was terminated removed the warning. To > terminate the executor, I used the shutdown() method followed by a loop > with a call to awaitTermination(). > > -Terence Bandoian > > > > >> On Sun, Jan 31, 2016 at 8:18 PM, Yuval Schwartz > > >> wrote: >> >> >>> On Sunday, 31 January 2016, Mark Thomas wrote: >>> >>> On 31/01/2016 08:06, Yuval Schwartz wrote: >>>> >>>>> Hellow Mark, >>>>> >>>>> Thanks for the reply. >>>>> Follow up questions below. >>>>> >>>>> On Fri, Jan 29, 2016 at 6:22 PM, Mark Thomas wrote: >>>>> >>>>> On 29/01/2016 14:34, Yuval Schwartz wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> tomcat version: 8.0.22 >>>>>>> java: jdk1.8.0_05 >>>>>>> server: Amazon Linux AMI >>>>>>> >>>>>>> I get the following warning message in my catalina log when I >>>>>>> >>>>>> undeploy a >>>> >>>>> web application: >>>>>>> >>>>>>> *WARNING [ContainerBackgroundProcessor[StandardEngine[Catalina]]] >>>>>>> >>>>>>> >>>> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads >>>> >>>>> The >>>>>> >>>>>>> web application [ROOT##002] appears to have started a thread named >>>>>>> [pool-2-thread-1] but has failed to stop it. This is very likely to >>>>>>> >>>>>> create >>>>>> >>>>>>> a memory leak. Stack trace of thread* >>>>>>> >>>>>>> As you can see, for some reason, I don't get a stack trace of the >>>>>>> >>>>>> thread. >>>> >>>>> Therefore, I have no idea how to debug this warning. >>>>>>> >>>>>>> This particular warning was generated when tomcat detected an unused >>>>>>> version and undeployed it (I set undeployOldVersions="true"). >>>>>>> >>>>>>> Does anyone know how I can debug this warning. How can I know more >>>>>>> >>>>>> about >>>> >>>>> this thread? >>>>>>> >>>>>> T
Re: WebAppClassLoaderBase.clearReferencesThreads warning
Hello Mark, I think that the issue below was related to the way I was shutting down an instance of ScheduledExecutorService. I changed the way it is shutdown when the context is destroyed...I will update here if I don't receive any more warnings. However, I now get a warning: WARNING [main] org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor The executor associated with thread pool [http-apr-8080] has not fully shutdown. Some application threads may still be running I am not sure if this is related or not? When I do a heap dump with jstack I see http-apr-8080-exec-[1-10] but I don't see any thread named http-apr-8080. Any ideas on how to trouble shoot this? Thanks. On Sun, Jan 31, 2016 at 8:18 PM, Yuval Schwartz wrote: > > > On Sunday, 31 January 2016, Mark Thomas wrote: > >> On 31/01/2016 08:06, Yuval Schwartz wrote: >> > Hellow Mark, >> > >> > Thanks for the reply. >> > Follow up questions below. >> > >> > On Fri, Jan 29, 2016 at 6:22 PM, Mark Thomas wrote: >> > >> >> On 29/01/2016 14:34, Yuval Schwartz wrote: >> >>> Hello, >> >>> >> >>> tomcat version: 8.0.22 >> >>> java: jdk1.8.0_05 >> >>> server: Amazon Linux AMI >> >>> >> >>> I get the following warning message in my catalina log when I >> undeploy a >> >>> web application: >> >>> >> >>> *WARNING [ContainerBackgroundProcessor[StandardEngine[Catalina]]] >> >>> >> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads >> >> The >> >>> web application [ROOT##002] appears to have started a thread named >> >>> [pool-2-thread-1] but has failed to stop it. This is very likely to >> >> create >> >>> a memory leak. Stack trace of thread* >> >>> >> >>> As you can see, for some reason, I don't get a stack trace of the >> thread. >> >>> Therefore, I have no idea how to debug this warning. >> >>> >> >>> This particular warning was generated when tomcat detected an unused >> >>> version and undeployed it (I set undeployOldVersions="true"). >> >>> >> >>> Does anyone know how I can debug this warning. How can I know more >> about >> >>> this thread? >> >> That looks like a thread from Commons Pool (possibly via DBCP). The >> only >> >> way to be sure you have a leak or not is to use a profiler. See >> >> >> >> >> http://home.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf >> > >> > >> > Is VisualVM a good profiler to start with considering my system? >> >> Sorry, don't know. Never used it. I use YourKit, mainly because they >> kindly donate free licenses to OpenSource developers to use with their >> OpenSource projects. > > > Thank you Mark, > > I installed VisualVM as a profiler. > I can now see all of the threads that tomcat is "using" (?not sure if > that's the correct term) (there's 35 live threads and 33 daemon threads). > Do you have any recommendations for how I might trouble shoot the original > warning that I got? Would I do a "heap dump"? > I have restarted tomcat since the time of the original warning message, so > I can't expect to find the same thread, correct? > Any tips? > > FYI: I never saw my cpu climbing or anything, I am troubleshooting this > warning solely on seeing the "Warning" message. Is this overkill? Should I > wait until something more severe occurs? (I have not yet gone live with my > webapp but planned on doing so soon). > > Thanks. > > >> >> Mark >> >> > I would just like to confirm that this warning is not something serious. >> > I am currently having a little trouble running VisualVM (jstatd) from a >> > remote machine but can struggle with it a little more to try to get it >> > working. >> > >> > >> > Thanks. >> > >> > >> > >> >> >> >>> I used the manager app and clicked "find leaks" but it said that there >> >> were >> >>> none. >> >>> (Can someone also explain why I have to be cautious when using this >> >> feature >> >>> on production environments). >> >> >> >> It triggers a full GC which may (hopefully briefly) pause the entire >> JVM. >> >> >> >> Mark >> >> >> >> >> >> - >> >> 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: WebAppClassLoaderBase.clearReferencesThreads warning
On Sunday, 31 January 2016, Mark Thomas wrote: > On 31/01/2016 08:06, Yuval Schwartz wrote: > > Hellow Mark, > > > > Thanks for the reply. > > Follow up questions below. > > > > On Fri, Jan 29, 2016 at 6:22 PM, Mark Thomas wrote: > > > >> On 29/01/2016 14:34, Yuval Schwartz wrote: > >>> Hello, > >>> > >>> tomcat version: 8.0.22 > >>> java: jdk1.8.0_05 > >>> server: Amazon Linux AMI > >>> > >>> I get the following warning message in my catalina log when I undeploy > a > >>> web application: > >>> > >>> *WARNING [ContainerBackgroundProcessor[StandardEngine[Catalina]]] > >>> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads > >> The > >>> web application [ROOT##002] appears to have started a thread named > >>> [pool-2-thread-1] but has failed to stop it. This is very likely to > >> create > >>> a memory leak. Stack trace of thread* > >>> > >>> As you can see, for some reason, I don't get a stack trace of the > thread. > >>> Therefore, I have no idea how to debug this warning. > >>> > >>> This particular warning was generated when tomcat detected an unused > >>> version and undeployed it (I set undeployOldVersions="true"). > >>> > >>> Does anyone know how I can debug this warning. How can I know more > about > >>> this thread? > >> That looks like a thread from Commons Pool (possibly via DBCP). The only > >> way to be sure you have a leak or not is to use a profiler. See > >> > >> > http://home.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf > > > > > > Is VisualVM a good profiler to start with considering my system? > > Sorry, don't know. Never used it. I use YourKit, mainly because they > kindly donate free licenses to OpenSource developers to use with their > OpenSource projects. Thank you Mark, I installed VisualVM as a profiler. I can now see all of the threads that tomcat is "using" (?not sure if that's the correct term) (there's 35 live threads and 33 daemon threads). Do you have any recommendations for how I might trouble shoot the original warning that I got? Would I do a "heap dump"? I have restarted tomcat since the time of the original warning message, so I can't expect to find the same thread, correct? Any tips? FYI: I never saw my cpu climbing or anything, I am troubleshooting this warning solely on seeing the "Warning" message. Is this overkill? Should I wait until something more severe occurs? (I have not yet gone live with my webapp but planned on doing so soon). Thanks. > > Mark > > > I would just like to confirm that this warning is not something serious. > > I am currently having a little trouble running VisualVM (jstatd) from a > > remote machine but can struggle with it a little more to try to get it > > working. > > > > > > Thanks. > > > > > > > >> > >>> I used the manager app and clicked "find leaks" but it said that there > >> were > >>> none. > >>> (Can someone also explain why I have to be cautious when using this > >> feature > >>> on production environments). > >> > >> It triggers a full GC which may (hopefully briefly) pause the entire > JVM. > >> > >> Mark > >> > >> > >> - > >> 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: WebAppClassLoaderBase.clearReferencesThreads warning
Hellow Mark, Thanks for the reply. Follow up questions below. On Fri, Jan 29, 2016 at 6:22 PM, Mark Thomas wrote: > On 29/01/2016 14:34, Yuval Schwartz wrote: > > Hello, > > > > tomcat version: 8.0.22 > > java: jdk1.8.0_05 > > server: Amazon Linux AMI > > > > I get the following warning message in my catalina log when I undeploy a > > web application: > > > > *WARNING [ContainerBackgroundProcessor[StandardEngine[Catalina]]] > > org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads > The > > web application [ROOT##002] appears to have started a thread named > > [pool-2-thread-1] but has failed to stop it. This is very likely to > create > > a memory leak. Stack trace of thread* > > > > As you can see, for some reason, I don't get a stack trace of the thread. > > Therefore, I have no idea how to debug this warning. > > > > This particular warning was generated when tomcat detected an unused > > version and undeployed it (I set undeployOldVersions="true"). > > > > Does anyone know how I can debug this warning. How can I know more about > > this thread? > That looks like a thread from Commons Pool (possibly via DBCP). The only > way to be sure you have a leak or not is to use a profiler. See > > http://home.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf Is VisualVM a good profiler to start with considering my system? I would just like to confirm that this warning is not something serious. I am currently having a little trouble running VisualVM (jstatd) from a remote machine but can struggle with it a little more to try to get it working. Thanks. > > > I used the manager app and clicked "find leaks" but it said that there > were > > none. > > (Can someone also explain why I have to be cautious when using this > feature > > on production environments). > > It triggers a full GC which may (hopefully briefly) pause the entire JVM. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
WebAppClassLoaderBase.clearReferencesThreads warning
Hello, tomcat version: 8.0.22 java: jdk1.8.0_05 server: Amazon Linux AMI I get the following warning message in my catalina log when I undeploy a web application: *WARNING [ContainerBackgroundProcessor[StandardEngine[Catalina]]] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT##002] appears to have started a thread named [pool-2-thread-1] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread* As you can see, for some reason, I don't get a stack trace of the thread. Therefore, I have no idea how to debug this warning. This particular warning was generated when tomcat detected an unused version and undeployed it (I set undeployOldVersions="true"). Does anyone know how I can debug this warning. How can I know more about this thread? I used the manager app and clicked "find leaks" but it said that there were none. (Can someone also explain why I have to be cautious when using this feature on production environments). Thank you
Re: Installing APR based Apache Tomcat Native Library
Thank you Christoph, I installed a compiled version from the distros on my production servers and I installed the binary version from http://tomcat.apache.org/download-native.cgi on my development server. A slight problem is that when I install from the distros I don't have control of the version and therefore there is a slight mismatch between my development and production environments (development version: Apache Tomcat Native Library 1.1.34 using APR 1.5.1, production version: Apache Tomcat Native Library 1.1.33 using APR 1.5.1) Thank you On Thu, Jan 28, 2016 at 10:27 AM, Christoph Nenning < christoph.nenn...@lex-com.net> wrote: > > Hello, > > > > tomcat version: 8.0.22 > > java: jdk1.8.0_05 > > server: Amazon Linux AMI > > > > When deploying my web application to my production environment (detailed > > above), I get a message: > > > > > > > > *The APR based Apache Tomcat Native library which allows optimal > > performance in production environments was not found on the > > java.library.path* > > So I wanted to install the Apache Tomcat Native library (does this > improve > > performance even for a web app that doesn't use SSL?) > > According to the documentation: http://tomcat.apache.org/native-doc/ > > I installed the apr-devel and openssl-devel packages with the command: > > > > yum install apr-devel openssl-devel > > > > However, I don't understand the next part of the instructions which > > discusses the "make && make install" command. > > From where do I run this command? I searched and I could not find a > > "jni/native" directory. > > From where do I run the "./configure --help" command and the other > > "./configure" commands? > > > > Thank you. > > > Those commands mean you compile source code of those libraries. So you > have to either download source code as zip archives and extract them or > check it out from version control. You probably need more C development > tools like a compiler. > > > Instead of compiling it yourself you can try to install a precompiled > version from your linux disros repositories: > > yum install apr tomcat-native > > If you use a recent version of tomcat it might happen that precompiled > libraries are outdated. > > If you just want to avoid that log message you can disable apr connector > AprLifecycleListener in server.xml. > > > > Regards, > Christoph > > This Email was scanned by Sophos Anti Virus >
Installing APR based Apache Tomcat Native Library
Hello, tomcat version: 8.0.22 java: jdk1.8.0_05 server: Amazon Linux AMI When deploying my web application to my production environment (detailed above), I get a message: *The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path* So I wanted to install the Apache Tomcat Native library (does this improve performance even for a web app that doesn't use SSL?) According to the documentation: http://tomcat.apache.org/native-doc/ I installed the apr-devel and openssl-devel packages with the command: yum install apr-devel openssl-devel However, I don't understand the next part of the instructions which discusses the "make && make install" command. >From where do I run this command? I searched and I could not find a "jni/native" directory. >From where do I run the "./configure --help" command and the other "./configure" commands? Thank you.
Re: Fwd:
On Tue, Nov 24, 2015 at 3:35 PM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > > Subject: Re: Fwd: > > > > First of all, I have a context.xml file in the WEB-INF folder of my > > > application (call it "myApplication" henceforth) that looks like: > This was a typo, I meant META-INF. Thanks > > Also note that WEB-INF is not the correct directory for context.xml. The > OP really, really needs to read the documentation: > http://tomcat.apache.org/tomcat-8.0-doc/config/context.html > > The OP also needs to learn to use a subject line - he has a history of > failing to do so. > > - Chuck > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Fwd:
Thanks a lot Christopher, my response is below. On Tue, Nov 24, 2015 at 2:26 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > Yuval, > > On 11/23/15 8:38 AM, Yuval Schwartz wrote: > > I am using tomcat 8.0.22.0 > > Language: Java > > development: Windows, NetBeans. > > deployment: ec2 linux > > > > I am still having trouble understanding/working with "path" and "docBase" > > of context element. > > > > I have two questions: > > > > First of all, I have a context.xml file in the WEB-INF folder of my > > application (call it "myApplication" henceforth) that looks like: > > > > > > You should never specify the "path" attribute in your context.xml file. > Instead, name the WAR file (or exploded directory) the same name as you > want your context's path to be. For a path of "" (empty), use the name > ROOT.war (or ROOT directory). > Executed. However, when I work in my development/local environment (not sure what the correct terminology is for this) I still specify path="" (since, when deploying with netbeans, a file is not generated in the tomcat/webapps directory). Is there a preferred way to do this on my local environment? When deployed on a Linux server, Is it ok to modify the context.xml file in tomcat/webapps/myApplication/META-INF (I think tomcat automcatically redeployed after I made a change)? > > > > maxActive="100" maxIdle="30" maxWait="1" > > username="blah" password="blahblah" > > driverClassName="com.mysql.jdbc.Driver" > > url="jdbc:mysql://localhost:3306/some_db?autoReconnect=true" > > logAbandoned="true" removeAbandoned="true" > > removeAbandonedTimeout="60" type="javax.sql.DataSource" /> > > > > > > My context path is set to the empty string because once I set up a domain > > name it will be redundant to have both the application name and domain > name > > in the url (they are the same). > > See above. > > > This works on my development environment. > > You may notice that your application is deployed on both context paths, > taking up twice as much heap space. Or it might not. Using "path" within > a context.xml file not well-defined, but it is expressly prohibited in > the documentation[1] though not actively prohibited by code. > > > When I deploy this to a linux server of an ec2 instance (on aws) I add a > > line to the server.xml file (in tomcat/conf) under the element > which > > reads: > > > > You should not do this. Instead, drop your ROOT.war into Tomcat's > deployment directory. If you move to EBS, you'll just be deploying the WAR file anyway and shouldn't touch the application servers at all. > Right, I did this and it worked. When you say "EBS" do you mean Amazon's Elastic Beanstalk? or Amazon's Elastic Block Store? > > > (If I don't add this element to the server.xml file then entering just > the > > domain in the url takes me to the Apache Tomcat "successful installation" > > page rather than to the welcome page of myApplication). > > Use ROOT.war. > > > First question: > > Is this the correct way to set up tomcat so that my application has no > > context path? > > No. Note that it /does/ have a context path: it's just an empty string. > > > Not sure if this leads to the "double deployment" problem or > > not. When I open the tomcat manager I see two applications: one with > path: > > "/" and the other with path "/myApplication". (for some reason, I don't > > have the option to "undeploy" the application with path: "/") > > You don't have that option because you have put your into > server.xml. > Removed Context element from Server.xml. > > > Second question: > > The resource element within the context element of my context.xml file > > (located in WEB-INF) specifies a url that is specific to my development > (ie > > local) environment. > > Which URL? The JDBC URL? > The URL attribute of the Resource element, specified above as: url="jdbc:mysql://localhost:3306/some_db?autoReconnect=true" But I think you can disregard the sentence above. I'm not even sure that once I'll deploy I'll want to connect to my development DB instead of my deployed DB (ie: maybe I'll want to connect to the deployed DB in both cases...) > > > When I deploy myApplication to the ec2 inst
Re:
Update regarding my second question below...The first question is still
valid as is and I am still interested in input.
On Mon, Nov 23, 2015 at 3:38 PM, Yuval Schwartz
wrote:
> Hello,
>
> I am using tomcat 8.0.22.0
> Language: Java
> development: Windows, NetBeans.
> deployment: ec2 linux
>
> I am still having trouble understanding/working with "path" and "docBase"
> of context element.
> I have two questions:
>
> First of all, I have a context.xml file in the WEB-INF folder of my
> application (call it "myApplication" henceforth) that looks like:
>
>
> maxActive="100" maxIdle="30" maxWait="1"
> username="blah" password="blahblah"
> driverClassName="com.mysql.jdbc.Driver"
> url="jdbc:mysql://localhost:3306/some_db?autoReconnect=true"
> logAbandoned="true" removeAbandoned="true"
> removeAbandonedTimeout="60" type="javax.sql.DataSource" />
>
>
> My context path is set to the empty string because once I set up a domain
> name it will be redundant to have both the application name and domain name
> in the url (they are the same).
>
> This works on my development environment.
>
> When I deploy this to a linux server of an ec2 instance (on aws) I add a
> line to the server.xml file (in tomcat/conf) under the element which
> reads:
>
>
> (If I don't add this element to the server.xml file then entering just the
> domain in the url takes me to the Apache Tomcat "successful installation"
> page rather than to the welcome page of myApplication).
>
> First question:
> Is this the correct way to set up tomcat so that my application has no
> context path? Not sure if this leads to the "double deployment" problem or
> not. When I open the tomcat manager I see two applications: one with path:
> "/" and the other with path "/myApplication". (for some reason, I don't
> have the option to "undeploy" the application with path: "/")
>
> Second question:
> The resource element within the context element of my context.xml file
> (located in WEB-INF) specifies a url that is specific to my development (ie
> local) environment.
> When I deploy myApplication to the ec2 instance I would like the resource
> element to have a different url attribute (since it will now be connecting
> with a database on an aws server).
> One way that I found to do this was to add to the context.xml file in the
> tomcat/conf directory of my server. There I add a resource element (between
> the existing context element) which is identical to the one above only with
> a url attribute that points to the database hosted on aws.
>
> This way, my application is able to connect with my database without me
> changing any of the code in myApplication.
> However, my Catalina.log file displays:
> WARNING [localhost-startStop-1]
> org.apache.catalina.core.NamingContextListener.add Resource Failed to
> register in JMX: javax.naming.NamingException: Could not create resource
> factory instance [Root exception is java.lang.ClassNotFoundException:
> org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory]
>
> And my localhost.log file shows a nullpointerexception for the line in my
> code:
> ic.lookup("java:comp/env/jdbc/some_db");
> (Where ic is an InitialContext Object)
>
> There are also problems in the deployed website with some of the code that
> grabs data from the db (but some of the db related code works successfully).
>
It turns out that these warning and exceptions were caused because of
missing jar files in the JDK's jre/lib/ext folder.
tomcat-dbcp.jar is not available in amazon's tomcat8 AMI (my terminology
might be a bit off).
Instead, one needs to transfer both the commons-dbcp.jar and
commons-pool.jar from tomcat/lib into the JDK's jre/lib/ext folder
In addition, since this is not the default factory in the Resource element
that I declared (as was the case with tomcat-jdbc), you need to explicitly
specify it: factory="org.apache.commons.dbcp.BasicDataSourceFactory"
>
> Any insight or suggestions would be greatly appreciated.
> I'm new to a lot of this (extremely new to deploying to a server).
>
> Thank you
> _
>
>
>
>
>
>
>
Fwd:
Hello,
I am using tomcat 8.0.22.0
Language: Java
development: Windows, NetBeans.
deployment: ec2 linux
I am still having trouble understanding/working with "path" and "docBase"
of context element.
I have two questions:
First of all, I have a context.xml file in the WEB-INF folder of my
application (call it "myApplication" henceforth) that looks like:
My context path is set to the empty string because once I set up a domain
name it will be redundant to have both the application name and domain name
in the url (they are the same).
This works on my development environment.
When I deploy this to a linux server of an ec2 instance (on aws) I add a
line to the server.xml file (in tomcat/conf) under the element which
reads:
(If I don't add this element to the server.xml file then entering just the
domain in the url takes me to the Apache Tomcat "successful installation"
page rather than to the welcome page of myApplication).
First question:
Is this the correct way to set up tomcat so that my application has no
context path? Not sure if this leads to the "double deployment" problem or
not. When I open the tomcat manager I see two applications: one with path:
"/" and the other with path "/myApplication". (for some reason, I don't
have the option to "undeploy" the application with path: "/")
Second question:
The resource element within the context element of my context.xml file
(located in WEB-INF) specifies a url that is specific to my development (ie
local) environment.
When I deploy myApplication to the ec2 instance I would like the resource
element to have a different url attribute (since it will now be connecting
with a database on an aws server).
One way that I found to do this was to add to the context.xml file in the
tomcat/conf directory of my server. There I add a resource element (between
the existing context element) which is identical to the one above only with
a url attribute that points to the database hosted on aws.
This way, my application is able to connect with my database without me
changing any of the code in myApplication.
However, my Catalina.log file displays:
WARNING [localhost-startStop-1]
org.apache.catalina.core.NamingContextListener.add Resource Failed to
register in JMX: javax.naming.NamingException: Could not create resource
factory instance [Root exception is java.lang.ClassNotFoundException:
org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory]
And my localhost.log file shows a nullpointerexception for the line in my
code:
ic.lookup("java:comp/env/jdbc/some_db");
(Where ic is an InitialContext Object)
There are also problems in the deployed website with some of the code that
grabs data from the db (but some of the db related code works successfully).
Any insight or suggestions would be greatly appreciated.
I'm new to a lot of this (extremely new to deploying to a server).
Thank you
_
Re: Fwd:
On Wed, Nov 11, 2015 at 7:14 PM, Mark Eggers
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Yuval,
>
> On 11/11/2015 8:34 AM, Yuval Schwartz wrote:
> > Hello Mark,
> >
> > Thanks for the reply. I am interested in finding where the
> > Document Root is for my application ("applicationName"). As I
> > understand, since my Catatlina_Home = "c:\tomcat" and the ""
> > tag in the server.xml specifies "appbase='webapps'", it should be
> > under c:\tomcat\webapps...but it is not.
> >
> > Thanks again.
> >
>
> And it will only be there if you actually deploy the WAR file to
> Tomcat (and unpackWARs is set to true).
>
> It may be in a different directory if you use a context file. This is
> how NetBeans operates. It may not even exist (if unpackWARs is set to
> false).
>
> What are you doing that requires knowledge of Document Root? BTW,
> document root is really an Apache HTTPD concept, and not an Apache
> Tomcat concept.
>
>
I just want to place a favicon in the document root.
How can I do this?
Again, the default tomcat favicon was shown up until (I think) when I
changed one of my projects' context path from "applicationName" to "/".
Since then, the favicon has disappeared and I would like to see it again
(and to have a better understanding of these things since I hope to deploy
to a web server in the coming months).
> Also, it is the convention of this mailing list to either reply inline
> or (preferably) at the end of the message. See the following for the
> mailing list guidelines:
>
> http://tomcat.apache.org/lists.html
>
> (item 6 of the tomcat-users mailing list)
>
> . . . just my two cents
> /mde/
> >
> > On Wed, Nov 11, 2015 at 6:13 PM, Mark Eggers
> > wrote:
> >
> > Yuval,
> >
> > On 11/11/2015 7:06 AM, Yuval Schwartz wrote:
> >>>> Hello,
> >>>>
> >>>> I am using tomcat 8.0.22.0. My Catalina_Home is set to
> >>>> "C:\tomcat". IDE: Netbeans. Language: Java.
> >>>>
> >>>> For some reason, when I deploy a web application in Netbeans
> >>>> that has the name "applicationName" and context path:
> >>>> "/applicationName" I do not see the application in the
> >>>> c:\tomcat\webapps folder. Can someone help me figure out
> >>>> what is not configured correctly? All I see is 4 folders
> >>>> "docs, examples, host-manager, manager." Interestingly, if I
> >>>> undeploy one of these 4 folders in netbeans, then this change
> >>>> is reflected immediately in path c:\tomcat\webapps (ie: I see
> >>>> 3 folders). However, as I said, deploying "applicationName"
> >>>> does not result in the folder being available in
> >>>> c:\tomcat\webapps (as it should).
> >>>>
> >>>> The whole reason I got into this was because I stopped
> >>>> seeing the tomcat favicon in my application all of a sudden
> >>>> (I suspect because I changed the context path from
> >>>> "/applicationName" to "/"). Now I would like to see the
> >>>> favicon and would like to understand why I am not seeing the
> >>>> deployed application where I should.
> >>>>
> >>>> My application is deployed successfully and runs fine (I just
> >>>> don't see it in c:\tomcat\webapps).
> >>>>
> >>>> Thank you.
> >>>>
> >
> > This is due to how NetBeans deploys to Tomcat. NetBeans creates a
> > config.xml file and copies it to
> > %CATALINA_BASE%\conf\Catalina\localhost\appname.xml
> >
> > Inside the appname.xml, there's a docBase that points to where you
> > built your application (for me it's
> > ProjectName\target\artifact-id).
> >
> > This then makes use of Tomcat's default configuration to trigger
> > reloads of your web application when certain resources are
> > changed.
> >
> > Here's a link on how that deployment works:
> >
> > http://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html
> >
> > Look for Deploy using a Context configuration ".xml" file.
> >
> > . . . just my two cents /mde/
> >>
> >> -
> >>
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBAgAGBQJWQ3drAAoJEEFGbsYNeTwtGrcIAJfZWPY6O3ZV8F39Dp4QkTHC
> zPm6Vldg330YcgNUbaECmvtgWMmkhdAf2CJUTnJJT5FM1m6PICMnl9RKzbCJi2KR
> 2nYlrMlY3J08cEPAKVn9Tac5UiPl7H+uSQOAxLL2IJ7RCcjFpyeLzbFJv/8Ii7Xd
> K7Y8C+FIw1iNpFYM+H+UqQhxdJZ3eYAzT3aBtdqZDdIOUAiiz8qLYTwC/pUNS5rn
> G5s0EJXQQk191870l4UtU8cIY6yW93dqeSEyANp132vFOdLTiI0jInqQmnEBZSYq
> LcCBAoJbOMufnxtrcmoJd+MzHx9XIQ5m5A61EJyr12zuUdSERKCCHCBwVEFDnZU=
> =pQNF
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Fwd:
Hello Mark,
Thanks for the reply.
I am interested in finding where the Document Root is for my application
("applicationName").
As I understand, since my Catatlina_Home = "c:\tomcat" and the "" tag
in the server.xml specifies "appbase='webapps'", it should be under
c:\tomcat\webapps...but it is not.
Thanks again.
On Wed, Nov 11, 2015 at 6:13 PM, Mark Eggers
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Yuval,
>
> On 11/11/2015 7:06 AM, Yuval Schwartz wrote:
> > Hello,
> >
> > I am using tomcat 8.0.22.0. My Catalina_Home is set to "C:\tomcat".
> > IDE: Netbeans. Language: Java.
> >
> > For some reason, when I deploy a web application in Netbeans that
> > has the name "applicationName" and context path: "/applicationName"
> > I do not see the application in the c:\tomcat\webapps folder. Can
> > someone help me figure out what is not configured correctly? All I
> > see is 4 folders "docs, examples, host-manager, manager."
> > Interestingly, if I undeploy one of these 4 folders in netbeans,
> > then this change is reflected immediately in path c:\tomcat\webapps
> > (ie: I see 3 folders). However, as I said, deploying
> > "applicationName" does not result in the folder being available in
> > c:\tomcat\webapps (as it should).
> >
> > The whole reason I got into this was because I stopped seeing the
> > tomcat favicon in my application all of a sudden (I suspect because
> > I changed the context path from "/applicationName" to "/"). Now I
> > would like to see the favicon and would like to understand why I am
> > not seeing the deployed application where I should.
> >
> > My application is deployed successfully and runs fine (I just
> > don't see it in c:\tomcat\webapps).
> >
> > Thank you.
> >
>
> This is due to how NetBeans deploys to Tomcat. NetBeans creates a
> config.xml file and copies it to
> %CATALINA_BASE%\conf\Catalina\localhost\appname.xml
>
> Inside the appname.xml, there's a docBase that points to where you
> built your application (for me it's ProjectName\target\artifact-id).
>
> This then makes use of Tomcat's default configuration to trigger
> reloads of your web application when certain resources are changed.
>
> Here's a link on how that deployment works:
>
> http://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html
>
> Look for Deploy using a Context configuration ".xml" file.
>
> . . . just my two cents
> /mde/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBAgAGBQJWQ2kWAAoJEEFGbsYNeTwtHpcH/2YsibyvjQcWTekK+YMmDqIn
> 64oE2+S274JWKQLnfkSbtQnUoGHqQRb2RpmUPPLXvyBWmRQ3NXoujduhESpiITd+
> os6Xz4TXQ4qa/Q0LQJlvBwfBcJeV8LE4AOK7PyImzOlKrQX2o1+547hSLPELSqtg
> f9xFtvL06ACgjauvXDPETW8hcgbvHIsQ5dYso44lW0fdYz+1r7VbsoeuIp7fOrgw
> EVV+Tp8jIpLvze3vGw04G9JlhGOJoqz4ePb4/xzDLsboGO4oHSeYHviMQ1gyZ4zY
> vEGPENRvv/1K/nBHa8WB1fcje2vJ0326n5z3Q9+z4zrvL8IaH4Fyaqf5t4disFA=
> =qg7p
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Fwd:
Hello, I am using tomcat 8.0.22.0. My Catalina_Home is set to "C:\tomcat". IDE: Netbeans. Language: Java. For some reason, when I deploy a web application in Netbeans that has the name "applicationName" and context path: "/applicationName" I do not see the application in the c:\tomcat\webapps folder. Can someone help me figure out what is not configured correctly? All I see is 4 folders "docs, examples, host-manager, manager." Interestingly, if I undeploy one of these 4 folders in netbeans, then this change is reflected immediately in path c:\tomcat\webapps (ie: I see 3 folders). However, as I said, deploying "applicationName" does not result in the folder being available in c:\tomcat\webapps (as it should). The whole reason I got into this was because I stopped seeing the tomcat favicon in my application all of a sudden (I suspect because I changed the context path from "/applicationName" to "/"). Now I would like to see the favicon and would like to understand why I am not seeing the deployed application where I should. My application is deployed successfully and runs fine (I just don't see it in c:\tomcat\webapps). Thank you.
Re: Fwd: Fwd:
Hello Chris,
Answers below.
Thanks again.
On Mon, May 25, 2015 at 3:18 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Yuval,
>
> On 5/24/15 5:06 PM, Yuval Schwartz wrote:
> > Firstly, I'd like to clear something up: Is container managed
> > security security only intended for use with administrative users
> > of a web application?
>
> No. What would give you that impression?
>
> > Because I was intending on using it for all users of my web
> > application (eg: customers, students, etc. People with no
> > administrative responsibilities).
>
> You can use it with everyone.
>
> > On Sun, May 24, 2015 at 9:00 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Yuval,
> >
> > On 5/23/15 7:15 AM, Yuval Schwartz wrote:
> >>>> I can currently initialize a MessageDigestCredentialHandler
> >>>> object with my desired salt, iteration and algorithm
> >>>> parameters and then call the handler's mutate() method before
> >>>> inserting the password into my database.
> >
> > Good.
> >
> >>>> And, from a servlet, the HttpServletRequest Object's login()
> >>>> (for example) method works when inputting the user_name and
> >>>> plain text password.
> >
> > Good.
> >
> >>>> However, I am still struggling to create my database input
> >>>> ({salt}:{iterations}:{hash}) without inputting my desired
> >>>> parameter (iterations, saltLength, etc.) to a
> >>>> MessageDigestCredentialHandler, but rather by getting these
> >>>> parameters (or the CredentialHandler itself) from the
> >>>> servlet.
> >
> > What have you tried? Do you want the remote user to be able to
> > specify the salt size and iterations?
> >
> >> I'd advise against that, since users may
> > intentionally reduce their own security (or, worse, intentionally
> > give you an effectively infinite salt or iteration count, which
> > could represent a DOS vulnerability).
> >
> >>>> Without being able to do this, I don't see the purpose of
> >>>> specifying these parameters in the nested
> >>>> element within the element of the
> >>>> context.xml file (these parameters are retrieved from the
> >>>> "storedCredential" when authenticating meaning they're not
> >>>> used when a method such as request.login() is performed).
> >
> > The are absolutely used when HttpServletRequest.login() is called.
> > That login() method ultimately calls Realm.authenticate(), which
> > uses the CredentialHandler. The settings in CredentialHandler
> > entirely handle logins for existing users.
> >
> >
> >> Realm.authenticate() calls
> >> MessageDigestCredentialHandler.matches(inputCredential,
> >> storedCredential) calls
> >> DigestCredentialHandlerBase.matchesSaltIterationsEncoded(inputCredent
> ials,
> >>
> >>
> storedCredentials) (line 146 of class MessageDigestCredentialHandler)
> >> This method isolates the salt from the storedCredential (line
> >> 162) Then isolates the iterations from the storedCredential (line
> >> 164) Then uses both these parameters in addition to the
> >> inputCredential to call MessageDigestCredentialHandler.mutate(
> >> inputCredential, salt, iterations). Then does calls the equals
> >> method of String class to compare the mutated results.
> >
> >> Therefore I concluded that the salt and iterations are taken from
> >> the stored password when authenticate() is called.
>
> Correct: both the salt and iteration could is stored in the database
> along with the actual hashed credential.
>
> >> Also, if I change the iterations and saltLength in my context.xml
> >> file, authentication is still successful regardless of the values
> >> I input.
>
> Correct: the stored credentials still include the salt length and
> iteration count. If you specify the "iterations" and "saltLength" in
> context.xml, they will be applied to the CredentialHandler object, but
> no code actually uses that.
>
> Note that neither the "saltLength" nor the "iterations" attributes are
> documented in the Tomcat users' guide... because they are unnecessary.
>
> >> Did I configure something incorrectly?
> >
> > It looks like you are struggling to create the stores
Re: Fwd: Fwd:
Hello,
Firstly, I'd like to clear something up:
Is container managed security security only intended for use with
administrative users of a web application?
Because I was intending on using it for all users of my web application
(eg: customers, students, etc. People with no administrative
responsibilities).
I have some more follow up questions and they are below.
Thank you again for your time.
On Sun, May 24, 2015 at 9:00 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Yuval,
>
> On 5/23/15 7:15 AM, Yuval Schwartz wrote:
> > I can currently initialize a MessageDigestCredentialHandler object
> > with my desired salt, iteration and algorithm parameters and then
> > call the handler's mutate() method before inserting the password
> > into my database.
>
> Good.
>
> > And, from a servlet, the HttpServletRequest Object's login() (for
> > example) method works when inputting the user_name and plain text
> > password.
>
> Good.
>
> > However, I am still struggling to create my database input
> > ({salt}:{iterations}:{hash}) without inputting my desired
> > parameter (iterations, saltLength, etc.) to a
> > MessageDigestCredentialHandler, but rather by getting these
> > parameters (or the CredentialHandler itself) from the servlet.
>
> What have you tried? Do you want the remote user to be able to specify
> the salt size and iterations?
I'd advise against that, since users may
> intentionally reduce their own security (or, worse, intentionally give
> you an effectively infinite salt or iteration count, which could
> represent a DOS vulnerability).
>
> > Without being able to do this, I don't see the purpose of
> > specifying these parameters in the nested
> > element within the element of the context.xml file (these
> > parameters are retrieved from the "storedCredential" when
> > authenticating meaning they're not used when a method such as
> > request.login() is performed).
>
> The are absolutely used when HttpServletRequest.login() is called.
> That login() method ultimately calls Realm.authenticate(), which uses
> the CredentialHandler. The settings in CredentialHandler entirely
> handle logins for existing users.
>
Realm.authenticate() calls
MessageDigestCredentialHandler.matches(inputCredential, storedCredential)
calls
DigestCredentialHandlerBase.matchesSaltIterationsEncoded(inputCredentials,
storedCredentials) (line 146 of class MessageDigestCredentialHandler)
This method isolates the salt from the storedCredential (line 162)
Then isolates the iterations from the storedCredential (line 164)
Then uses both these parameters in addition to the inputCredential to call
MessageDigestCredentialHandler.mutate( inputCredential, salt, iterations).
Then does calls the equals method of String class to compare the mutated
results.
Therefore I concluded that the salt and iterations are taken from the
stored password when authenticate() is called.
Also, if I change the iterations and saltLength in my context.xml file,
authentication is still successful regardless of the values I input.
Did I configure something incorrectly?
>
> It looks like you are struggling to create the stores credentials in
> the first place (e.g. in a "change password" or "register" workflow).
>
I wanted to do it by getting the same MessageDigestCredentialHandler that I
defined in the context.xml in my servlet.
But since I am not able to, I just initialize a new
MessageDigestCredentialHandler and use that to create the stored
credentials.
Is there any way to authenticate a user using just the stored credential
(ie: I don't have the plain text password. I only have the storedCredential
and I want to call request.login(). Is that possible?
Thanks.
>
> > The way my code is now there is no purpose to specifying saltLength
> > and iterations in the context.xml file.
>
> Does that mean you have hard-coded the salt length and iterations in
> your credential-generating algorithm? I'd advise against that because
> you may want to modify the salt size or number of iterations in the
> future, and you don't want to have to re-compile your code to do that.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVYhHEAAoJEBzwKT+lPKRYqjwP/A/+uLxfqKhiYcnnsnz+L64f
> l4Bwde+wy+QJh5/0A90KVSbBi7BS0x9/khOCm+xjGMNtH7BeApMW+h+haBXEbAZW
> ANFLLYv+4yJEFuz1Kz3jmtXkdwHpKRf9a7eN7HMwDfslZFaH+HgF1szzzaWVeV9i
> 398+5R5fiUqZZfVqp6TpZ3rh4TdmtwxbWgNWmiBz5pFrRvg9Uq+vOr6JQBYjsuu0
> l9rNepJjHItvxEv+cvCY4xaJjdKhHd4xM2XgTuG60YT7MsItlRvMiYsUnM41oPJU
> 9KTI30wAC3DacVwj7ChFzQIgAP1NaGfbLFSsie4xqey
Re: Fwd: Fwd:
Hello Chris,
Thanks once again.
I can currently initialize a MessageDigestCredentialHandler object with my
desired salt, iteration and algorithm parameters and then call the
handler's mutate() method before inserting the password into my database.
And, from a servlet, the HttpServletRequest Object's login() (for example)
method works when inputting the user_name and plain text password.
However, I am still struggling to create my database input
({salt}:{iterations}:{hash}) without inputting my desired parameter
(iterations, saltLength, etc.) to a MessageDigestCredentialHandler, but
rather by getting these parameters (or the CredentialHandler itself) from
the servlet.
Without being able to do this, I don't see the purpose of specifying these
parameters in the nested element within the
element of the context.xml file (these parameters are retrieved from the
"storedCredential" when authenticating meaning they're not used when a
method such as request.login() is performed).
The way my code is now there is no purpose to specifying saltLength and
iterations in the context.xml file.
Thanks
_
Yuval
On Fri, May 22, 2015 at 8:17 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Yuval,
>
> On 5/22/15 9:54 AM, Yuval Schwartz wrote:
> > I wasn't aware that I can look at the actual classes but I wasn't
> > able to find a precompiled version of RealmBase for tomcat 8.
>
> You mean you didn't know you could look at the source code for Tomcat?
> It's open-source software, like like everything else at the Apache
> Software Foundation. Here's a link directly into the Subversion
> repository for the RealmBase code:
> http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catali
> na/realm/RealmBase.java?view=markup
>
> You can also pull the whole source tree from Subversion, or download a
> source distribution:
> http://tomcat.apache.org/download-80.cgi#Source_Code_Distributions
>
> > The following is a link to the class of version 7 (which doesn't
> > include the CredentialHandler code):
> > http://grepcode.com/file/repository.springsource.com/org.apache.catali
> na/com.springsource.org.apache.catalina/7.0.26/org/apache/catalina/realm
> /RealmBase
>
> Looking
> >
> at Tomcat 7 won't help, as you said: the CredentialHandler
> code is not in there.
>
> > When I try to view this file from my netbeans IDE (which is the
> > correct version), I get the compiled version. Do you know how I can
> > view the file that's not compiled?
>
> See above. This is the beauty of open source software :)
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVX2SPAAoJEBzwKT+lPKRYxVAQAL4tp2cWv/xcVjEQ1BgnTAFT
> tlnBrBwVxRQvUsemByZ4DzGSQmkR6LFXFc0P95BLx7XBUB9AymGAL2CQdFevg3ah
> AUtwChNzu2Bfeu05fShHUNAGeJhArfxOpkYGtGX5VnD96XnyKCcTe2fME4vPm9hs
> 8VqsYr9bRLx0AhVmC2HgGan60DPGIjb/ZvFagS5nZDtj3/ZlYz+kkrN51POVcFXe
> EpWZi5lNBUNdeN1Dq+IbD9OqAkZJE/OjB2xdPPRGZfBeuXnzA97W2DrjCNTUpBHL
> wYsSxBoWjFVXtClZrn1Tkr1E72nWtKNu7mai7nou996c3oCvIZS92ev8SOIfb512
> BduEhPYeGI4vcTOv+Vtn02TTCApFjqD+OAxWfKtkT+Moau4L63qOeEedWKs9byVp
> lRKep137+ljyBDZXd9scArIs5RLShZBybkTTgyBc6v6ZJFsQiIF5Z3ow3Ox8v3u4
> w0gucKdiMEfQIorlmkCUgCUQDfzotammyaCg4O69N4dU7Okcla7Jpl1blv0YHCFf
> xnHVc0wXHQwRWdS+kJOsis8ScivXU5lYOS7vsRR3ZtKOadzE1rO4INHljpdK1G1T
> qySaZO0MH3k4BA3Gq1VIXpld2q7bWcEE8kaAiLl17LlBzSbGMSBik3uxl9PmF32N
> jjnMtokx3RX4oi1KaAD9
> =18f6
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Fwd: Fwd:
Thanks again Chris,
I wasn't aware that I can look at the actual classes but I wasn't able to
find a precompiled version of RealmBase for tomcat 8.
The following is a link to the class of version 7 (which doesn't include
the CredentialHandler code):
http://grepcode.com/file/repository.springsource.com/org.apache.catalina/com.springsource.org.apache.catalina/7.0.26/org/apache/catalina/realm/RealmBase
When I try to view this file from my netbeans IDE (which is the correct
version), I get the compiled version. Do you know how I can view the file
that's not compiled?
Thanks
On Thu, May 21, 2015 at 11:49 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Yuval,
>
> On 5/21/15 2:39 PM, Yuval Schwartz wrote:
> > Hello,
> >
> > I have some follow-up questions to Chris' response below (in
> > blue).
> >
> > On Wed, May 20, 2015 at 5:53 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Yuval,
> >
> > On 5/20/15 9:34 AM, Yuval Schwartz wrote:
> >>>> I believe I am running tomcat 8.0 (although when I call the
> >>>> getServerInfo() method of the implicit ServletContext Object
> >>>> It tells me that I am running on 7.54)
> >
> > Then you are not running Tomcat 8.0.x.
> >
> >>>> I configured my realm element in my context.xml file as
> >>>> follows (based on the howto guide:
> >>>> https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html):
> >
> > If you are running Tomcat 7, the Tomcat 8 users guide may give you
> > bad guidance. If you are intending to run Tomcat 8, you might want
> > to get that fixed, first.
> >
> >
> >> You are correct, I was running Tomcat 7, which doesn't use the
> >> same syntax for digesting from the command prompt (I think it
> >> doesn't have the options for salt, iterations, etc.). So I
> >> updated to tomcat 8.
>
> Correct: you'll need Tomcat 8 for the salting and iterative hashing.
>
> >>>> >>>> debug="99"
> >
> > The "debug" attribute hasn't been supported for something like 10
> > years.
> >
> >>>> dataSourceName="jdbc/board" localDataSource="true"
> >>>> userTable="test_user" userNameCol="Email"
> >>>> userCredCol="HashedPassword" userRoleTable="test_user_role"
> >>>> roleNameCol="Role">
> >>>>
> >>>> >>>> className="MessageDigestCredentialHandler" algorithm="SHA-1"
> >>>> iterations="1000" saltLength="48"/>
> >
> > Oh, good: someone is using the CredentialHandler to improve their
> > security. You might want to:
> >
> > 1. Switch to a larger hash, like SHA-256 2. Find out how much time
> > it takes to do 1000 SHA-1 (or SHA-256) hashes on your server. You
> > want the hashing to take more than a trivial amount of time. Our
> > services currently use more than 10k iterations of SHA-256. This
> > makes brute-forcing our password database very time consuming for
> > an attacker, if they were to capture the database itself.
> >
> >>>>
> >>>>
> >>>>
> >>>> However, despite the password being stored in the format
> >>>> described in your "how to" manual
> >>>> (ie:{salt}${iterations}${password}), authentication fails. I
> >>>> assume that this is because something in my
> >>>> configuration is wrong.
> >
> > Tomcat can generate a hash for you from the command-line:
> >
> > $ ./bin/digest.sh -a SHA-256 -i 1000 -s 48 'test'
> > test:04d9deb5f6f1f206c7139a28806e7ebde8f444018e0191168f8d00291d6e8719c
> d2
> >
> >
> 5cc82eca073f9a925c005aadf238b$1000$22cb9257949205ffbff01088b46137cf768dc
> > 67a0faca26f48269ca9250d4d9b
> >
> > Let's take-apart that credential to see what's in there:
> >
> > hash:
> >
> >
> >> Don't you mean "salt" above, instead of "hash:"?
>
> Yes.
>
> > 04d9deb5 f6f1f206 c7139a28 806e7ebd e8f44401 8e019116 8f8d0029
> > 1d6e8719 cd25cc82 eca073f9 a925c005 aadf238b
> >
> > That's 48 bytes (96 characters) of data.
> >
> > iteration count: 1000 (easy)
> >
> > fingerprint: 22cb9257 949205ff bff01088 b46137cf 768dc67a 0faca26f
> > 48269ca9 250d4d9b
Fwd: Fwd:
Hello,
I have some follow-up questions to Chris' response below (in blue).
On Wed, May 20, 2015 at 5:53 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Yuval,
>
> On 5/20/15 9:34 AM, Yuval Schwartz wrote:
> > I believe I am running tomcat 8.0 (although when I call the
> > getServerInfo() method of the implicit ServletContext Object It
> > tells me that I am running on 7.54)
>
> Then you are not running Tomcat 8.0.x.
>
> > I configured my realm element in my context.xml file as follows
> > (based on the howto guide:
> > https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html):
>
> If you are running Tomcat 7, the Tomcat 8 users guide may give you bad
> guidance. If you are intending to run Tomcat 8, you might want to get
> that fixed, first.
>
You are correct, I was running Tomcat 7, which doesn't use the same syntax
for digesting from the command prompt (I think it doesn't have the options
for salt, iterations, etc.). So I updated to tomcat 8.
>
> > > debug="99"
>
> The "debug" attribute hasn't been supported for something like 10 years.
>
> > dataSourceName="jdbc/board" localDataSource="true"
> > userTable="test_user" userNameCol="Email"
> > userCredCol="HashedPassword" userRoleTable="test_user_role"
> > roleNameCol="Role">
> >
> > > algorithm="SHA-1" iterations="1000" saltLength="48"/>
>
> Oh, good: someone is using the CredentialHandler to improve their
> security. You might want to:
>
> 1. Switch to a larger hash, like SHA-256
> 2. Find out how much time it takes to do 1000 SHA-1 (or SHA-256)
> hashes on your server. You want the hashing to take more than a
> trivial amount of time. Our services currently use more than 10k
> iterations of SHA-256. This makes brute-forcing our password database
> very time consuming for an attacker, if they were to capture the
> database itself.
>
> >
> >
> >
> > However, despite the password being stored in the format described
> > in your "how to" manual (ie:{salt}${iterations}${password}),
> > authentication fails. I assume that this is because something in my
> > configuration is wrong.
>
> Tomcat can generate a hash for you from the command-line:
>
> $ ./bin/digest.sh -a SHA-256 -i 1000 -s 48 'test'
> test:04d9deb5f6f1f206c7139a28806e7ebde8f444018e0191168f8d00291d6e8719cd2
> 5cc82eca073f9a925c005aadf238b$1000$22cb9257949205ffbff01088b46137cf768dc
> 67a0faca26f48269ca9250d4d9b
>
> Let's take-apart that credential to see what's in there:
>
> hash:
>
Don't you mean "salt" above, instead of "hash:"?
> 04d9deb5 f6f1f206
> c7139a28 806e7ebd
> e8f44401 8e019116
> 8f8d0029 1d6e8719
> cd25cc82 eca073f9
> a925c005 aadf238b
>
> That's 48 bytes (96 characters) of data.
>
> iteration count: 1000 (easy)
>
> fingerprint:
> 22cb9257 949205ff
> bff01088 b46137cf
> 768dc67a 0faca26f
> 48269ca9 250d4d9b
>
> That's 32 bytes (64 characters) of data. SHA-1 produces 32-byte
>
I think you mean "SHA-256" here, right?
> output, so this looks good on the face of it.
>
Yes, it looks correct.
My issue is that I would like to run this "digest" from a servlet. How
would I do that?
I need to run it from a servlet because I need to enter it into my database
(in the format {salt}${iterations}${passowrd}).
>
> > I was not able to find an answer on online help forums. I also
> > couldn't find a way to call the initialized DataSourceRealm
> > Object's digest method when inputting the HashedPassword (ie: I had
> > to calculate salt and hash on my own using the SHA-1 algorithm).
> > Perhaps this also has something to do with why authentication is
> > failing?
>
> You probably weren't following the algorithm the same way. For
> example, the 1000 iterations is done like this:
>
> cred = password
> do 1000 times:
> cred = hash ( salt + cred )
>
> You probably forgot to salt the credential for each of the iterations.
>
Should I even be doing it this way? This relates to my previous comment: Is
there no way to call the same digest function that we ran from the command
line, in a servlet?
Indeed there is a digest method as part of the RealmBase API, I just don't
know how to get an instance of the RealmBase Object from the servlet.
>
> Take a look at the RealmBase class to see how the stored credential
> should be generated initially.
>
>
I looked at the RealmBase cl
Fwd:
Hello,
I believe I am running tomcat 8.0 (although when I call the getServerInfo()
method of the implicit ServletContext Object It tells me that I am running
on 7.54)
I configured my realm element in my context.xml file as follows (based on
the howto guide: https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html):
However, despite the password being stored in the format described in your
"how to" manual (ie:{salt}${iterations}${password}), authentication fails.
I assume that this is because something in my configuration is
wrong.
I was not able to find an answer on online help forums.
I also couldn't find a way to call the initialized DataSourceRealm Object's
digest method when inputting the HashedPassword (ie: I had to calculate
salt and hash on my own using the SHA-1 algorithm). Perhaps this also has
something to do with why authentication is failing?
Thank you
