Java Mailing List Archive

http://www.junlu.com/

Home » users-digest.tomcat »

users Digest 29 Jan 2012 10:49:20 -0000 Issue 10781

users-digest-help

2012-01-29


Author Login • Post Reply

users Digest 29 Jan 2012 10:49:20 -0000 Issue 10781

Topics (messages 231569 through 231583):

Re: Correct behavior while checking the thread binding in DirContextURLStreamHandler ?
 231569 by: Ivan

Re: Reinstall with 302 error
 231570 by: Pid

[OT] Re: TC7 very slow SessionIdGenerator SecureRandom initialization
 231571 by: Pid

Re: Connectors: Http11Protocol vs. Http11NioProtocol
 231572 by: André Warnier
 231574 by: bxqdev
 231576 by: André Warnier

Re: How to configure certificate file (*.cer) in Tomcat 6
 231573 by: Pid

[OT] Re: Connectors: Http11Protocol vs. Http11NioProtocol
 231575 by: Pid

Re: connection autoReconnect?
 231577 by: Jerry Malcolm
 231578 by: Mark Eggers

Tomcat 6 - How to make an application available at www.mydomain.com
 231579 by: Dean Del Ponte
 231580 by: Caldarale, Charles R
 231581 by: Thomas Rohde
 231582 by: Borut Hadžialić
 231583 by: Borut Hadžialić

Administrivia:

---------------------------------------------------------------------
To post to the list, e-mail: users@(protected)
To unsubscribe, e-mail: users-digest-unsubscribe@(protected)
For additional commands, e-mail: users-digest-help@(protected)

----------------------------------------------------------------------


Attachment: users_231569.ezm (zipped)
So is the current behavior by design, or it is a defect ?

2012/1/28 Ivan <xhhsld@(protected)>

> Yes, but guess that getParent() will not be null in most scenarios :-) And
> if the thread binding value is expected to be returned while no classloader
> binding, think the codes should be in the end of the method.
>
> 2012/1/28 Caldarale, Charles R <Chuck.Caldarale@(protected)>
>
> > From: Ivan [mailto:xhhsld@(protected)]
>> > Subject: Correct behavior while checking the thread binding in
>> DirContextURLStreamHandler ?
>>
>> >      result = threadBindings.get(currentThread);
>> > <-------------- Here, the value from threadBindings is always ignored ?
>>
>> No, it's not always ignored. If
>> currentThread.getContextClassLoader().getParent() is null, the value from
>> ghreadBindings.get() will be returned. Of course, I don't know if the
>> getParent() call can ever return null; that might well depend on actions
>> taken inside the webapp application code.
>>
>> - Chuck
>>
>>
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>> MATERIAL and is thus for use only by the intended recipient. If you
>> received this in error, please contact the sender and delete the e-mail and
>> its attachments from all computers.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>> For additional commands, e-mail: users-help@(protected)
>>
>>
>
>
> --
> Ivan
>



--
Ivan

Attachment: users_231570.ezm (zipped)
On 28/01/2012 15:08, Bilal S wrote:
> It would not be unusual for a page to redirect to itself.
> Have you tried an alternate connection mechanisms. Http proxy or BonCode (
> http://tomcatiis.riaforge.org)?

Really, is that relevant here?

Please don't top-post. Please reply below each relevant point in the
previous message.


> Does it behave the same?
>
> If this app works unmodified in Mac OSX, it should work in Windows.
>
> On Wed, Jan 25, 2012 at 5:08 PM, Benjamin Madore <bcm37@(protected):
>
>> Hi all,
>>
>>           I have inherited a two web applications written several
>> years ago. Since the server, which had been installed just before I
>> arrived,
>> was rebuilt last month we have not been able to log in to the application.
>> We had continued to update Tomcat and Java before the rebuild so it was
>> running the latest versions at the time on Windows 2008.
>>
>> Previously we had been using IIS to redirect the site, however we installed
>> the Tomcat Connector.

Which versions of Tomcat and the connector are you using?


>> We use an SSL cert that has been installed in IIS.
>>
>> The index.jsp page loads fine, but other jsp pages in the site give an
>> error. Other sites have no problem, and I am able to view jsp pages with or
>> without https.

What is the error - be precise please.


>> One web app (the eli2117 and 2121 folders) won't load at all after the
>> login
>> page, and the other (dataSearch) appears normal, it will reload the login
>> page (related to a bug in the application, login was always flaky on it
>> unless you were logged into an instance of the former application).

What does "won't load" mean, in detail, please? An error?


>> Other pages (the test directory) load fine.
>>
>> The eli app uses "response.sendRedirect("home.jsp");" in the login process;
>> but it appears to me that even login.jsp is not being recognized from the
>> form submit.

Where is login.jsp? How are you accessing it? What kind of
authentication is configured?


>> We have a test server running Tomcat 6 and MacOS 10.4 where the application
>> works fine. I understand there is a big difference between the two, but the
>> budget for upgrades is thin around here. As I said before, it ran in the
>> current environment prior to the rebuild.
>>
>> I would appreciate any hints on where to go from here on fixing the
>> problem.
>>
>> Attached are log snippets.

Attachments get eaten by the list. Please paste log contents inline.


p


>> Thanks,
>>
>> Ben Madore
>>
>>
>>
>> Research Programmer, Linguistics Dpt.
>>
>> University of Pittsburgh, Cathedral of Learning
>>
>>
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:12 -0500] "GET /eli2121/ HTTP/1.1"
>> 200 6501
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "POST /eli2121/login.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 136.142.248.135 - - [24/Jan/2012:14:02:20 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>>
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:31 -0500] "GET
>> /eli2117/course.jsp?action=submit&file_type_id=1 HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:32 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:33 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:33 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:33 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:39 -0500] "GET
>> /eli2117/course.jsp?action=submit&file_type_id=1 HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:39 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:39 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:39 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:39 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:39 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:39 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:39 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:39 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:39 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:39 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:39 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:39 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:39 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:40 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:40 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:40 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:40 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:40 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:40 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 107.9.135.86 - - [25/Jan/2012:00:37:40 -0500] "GET /eli2117/home.jsp
>> HTTP/1.1" 302 -
>>
>> 199.21.99.98 - - [25/Jan/2012:05:10:08 -0500] "GET /eli2121/index.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.29 - - [25/Jan/2012:10:55:14 -0500] "GET /eli2121/index.new.jsp
>> HTTP/1.1" 200 6501
>>
>> 130.49.136.29 - - [25/Jan/2012:10:55:14 -0500] "GET /eli2121/css/style.css
>> HTTP/1.1" 200 2832
>>
>> 130.49.136.29 - - [25/Jan/2012:10:55:14 -0500] "GET
>> /eli2121/media/mm_spacer.gif HTTP/1.1" 200 43
>>
>> 130.49.136.29 - - [25/Jan/2012:10:55:14 -0500] "GET
>> /eli2121/media/collage.jpg HTTP/1.1" 200 16751
>>
>> 130.49.136.29 - - [25/Jan/2012:10:55:14 -0500] "GET
>> /eli2121/media/mm_dashed_line.gif HTTP/1.1" 200 1220
>>
>> 71.61.182.145 - - [25/Jan/2012:11:14:02 -0500] "GET /dataSearch/ HTTP/1.1"
>> 200 6408
>>
>> 71.61.182.145 - - [25/Jan/2012:11:14:02 -0500] "GET
>> /dataSearch/css/style.css HTTP/1.1" 200 2753
>>
>> 71.61.182.145 - - [25/Jan/2012:11:14:02 -0500] "GET
>> /dataSearch/media/collage.jpg HTTP/1.1" 200 16751
>>
>> 71.61.182.145 - - [25/Jan/2012:11:14:02 -0500] "GET
>> /dataSearch/media/mm_dashed_line.gif HTTP/1.1" 200 1220
>>
>> 71.61.182.145 - - [25/Jan/2012:11:14:02 -0500] "GET
>> /dataSearch/media/mm_spacer.gif HTTP/1.1" 200 43
>>
>> 71.61.182.145 - - [25/Jan/2012:11:14:11 -0500] "POST /dataSearch/login.jsp
>> HTTP/1.1" 200 5627
>>
>> 71.61.182.145 - - [25/Jan/2012:11:17:54 -0500] "GET /dataSearch/ HTTP/1.1"
>> 200 6408
>>
>> 71.61.182.145 - - [25/Jan/2012:11:17:59 -0500] "POST /dataSearch/login.jsp
>> HTTP/1.1" 200 5627
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/index.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/index.new.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:26 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:27 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:27 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:27 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:27 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:27 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:27 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:30 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:30 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:30 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:37:31 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:07 -0500] "GET /dataSearch/ HTTP/1.1"
>> 200 6408
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:07 -0500] "GET
>> /dataSearch/css/style.css HTTP/1.1" 200 2753
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:07 -0500] "GET
>> /dataSearch/media/collage.jpg HTTP/1.1" 200 16751
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:07 -0500] "GET
>> /dataSearch/media/mm_spacer.gif HTTP/1.1" 200 43
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:07 -0500] "GET
>> /dataSearch/media/mm_dashed_line.gif HTTP/1.1" 200 1220
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:13 -0500] "POST /dataSearch/login.jsp
>> HTTP/1.1" 200 5627
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:19 -0500] "POST /dataSearch/login.jsp
>> HTTP/1.1" 200 5627
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:29 -0500] "GET /eli2121/index.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:29 -0500] "GET /eli2121/index.new.jsp
>> HTTP/1.1" 200 6501
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:29 -0500] "GET /eli2121/css/style.css
>> HTTP/1.1" 200 2832
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:29 -0500] "GET
>> /eli2121/media/collage.jpg HTTP/1.1" 200 16751
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:29 -0500] "GET
>> /eli2121/media/mm_spacer.gif HTTP/1.1" 200 43
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:29 -0500] "GET
>> /eli2121/media/mm_dashed_line.gif HTTP/1.1" 200 1220
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "POST /eli2121/login.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:49:33 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:35 -0500] "GET /eli2121/ HTTP/1.1" 302
>> -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:35 -0500] "GET /eli2121/index.new.jsp
>> HTTP/1.1" 200 6501
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:46 -0500] "GET /test/ HTTP/1.1" 404
>> 970
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/index.new.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:49 -0500] "GET /eli2121/home.jsp
>> HTTP/1.1" 302 -
>>
>> 130.49.136.64 - - [25/Jan/2012:16:51:50 -0500] "GET /eli2121/index.new.jsp
>> HTTP/1.1" 200 6501
>>
>> 130.49.136.64 - - [25/Jan/2012:16:52:20 -0500] "GET /test/index.jsp
>> HTTP/1.1" 404 997
>>
>> 130.49.136.64 - - [25/Jan/2012:16:52:30 -0500] "GET /test/index.html
>> HTTP/1.1" 200 4200
>>
>> 130.49.136.64 - - [25/Jan/2012:16:52:31 -0500] "GET /test/intro.css
>> HTTP/1.1" 200 5569
>>
>> 130.49.136.64 - - [25/Jan/2012:16:52:31 -0500] "GET /test/img/collage.jpg
>> HTTP/1.1" 200 16751
>>
>> 130.49.136.64 - - [25/Jan/2012:16:52:31 -0500] "GET
>> /test/img/mm_dashed_line.gif HTTP/1.1" 200 1220
>>
>> 130.49.136.64 - - [25/Jan/2012:16:52:37 -0500] "GET /test/Date_Time.jsp
>> HTTP/1.1" 200 17805
>>
>> 130.49.136.64 - - [25/Jan/2012:16:52:37 -0500] "GET /test/mainmenu.css
>> HTTP/1.1" 200 8844
>>
>> 130.49.136.64 - - [25/Jan/2012:16:52:40 -0500] "GET /test/template-test.jsp
>> HTTP/1.1" 200 4432
>>
>> 130.49.136.64 - - [25/Jan/2012:16:52:44 -0500] "GET /test/tag-test.jsp
>> HTTP/1.1" 404 1006
>>
>> 130.49.136.64 - - [25/Jan/2012:16:53:10 -0500] "GET /test/logo.jsp
>> HTTP/1.1"
>> 200 6724
>>
>> 130.49.136.64 - - [25/Jan/2012:16:53:10 -0500] "GET /test/css/style.css
>> HTTP/1.1" 200 2621
>>
>> 130.49.136.64 - - [25/Jan/2012:16:53:10 -0500] "GET /test/media/collage.jpg
>> HTTP/1.1" 200 16751
>>
>> 130.49.136.64 - - [25/Jan/2012:16:53:10 -0500] "GET /test/img/pitt-logo.gif
>> HTTP/1.1" 200 8920
>>
>> 130.49.136.64 - - [25/Jan/2012:16:53:10 -0500] "GET
>> /test/media/mm_dashed_line.gif HTTP/1.1" 200 1220
>>
>> 130.49.136.64 - - [25/Jan/2012:16:53:10 -0500] "GET
>> /test/media/mm_spacer.gif HTTP/1.1" 200 43
>>
>>
>


--

[key:62590808]


Attachment: signature.asc (zipped)
Attachment: users_231571.ezm (zipped)
On 28/01/2012 14:23, Rainer Jung wrote:
> On 28.01.2012 00:38, Pid wrote:
>> On 27/01/2012 23:25, Caldarale, Charles R wrote:
>>>> From: David Rees [mailto:drees76@(protected)]
>>>> Subject: Re: TC7 very slow SessionIdGenerator SecureRandom
>>>> initialization
>>>
>>>> Hmm, yes, the systems I've checked running Java 1.7.0_02 list
>>>> /dev/urandom as the securerandom.source.
>>>
>>> Unfortunately, there's a misguided part of the JRE that insists it's
>>> smarter than any sysadmin, so it checks for /dev/urandom and uses
>>> /dev/random instead - that's why the setting of /dev/./urandom is
>>> important, even though it would seem to be equivalent.
>>
>> So editing the file fixes this, or just using the system property?
>
> I expect either will help.
>
> Using /dev/random instead of the configured /dev/urandom IMHO is an
> implementation bug. Some more details at
>
> http://marc.info/?l=tomcat-dev&m=130182757504685&w=2
>
> http://search.oracle.com/search/search?search_p_main_operator=all&start=1&group=bugs.sun.com&q=%2Fdev%2Furandom
>
>
> The one bug closest to this topic is
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6202721
>
> but Oracle doesn't care :(.

I wonder if the OpenJDK project will be more responsive.


p


> Regards,
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>


--

[key:62590808]


Attachment: signature.asc (zipped)
Attachment: users_231572.ezm (zipped)
Hi.

Your original question was

quote
1. What are the premises to use either apache.coyote.http11.Http11NioProtocol or
org.apache.coyote.http11.Http11NioProtocol connectors?
2. Do i get any advantages if i use Sync Servlet Api with Http11NioProtocol connector or
do i have to use Async Servlet Api to get the advantages?
3. How do i choose which one to use in any particular case?
unquote

and your conclusion is :

> well, let's separate the wheat from the chaff and arrogance:
>
> 1. nio connector is useful when one needs to handle a lot of
> client connections, keep-alive ones, for example.
> 2. async servlet is useful when one app thread can fulfill many responses.
> 3. communication between connector and async servlet should be called
> semi-async, rather than async, because request processing is
> sync anyway, although response processing is async.
>
> that could be a simple answer for my question in the first place.
> everything else is triteness.
> thanks anyway :)
> thread can be closed now.
>

If it were to happen that you would have a further need to make use of this list (or
another similar help forum), may I suggest that you fist read and ponder the document at
http://catb.org/esr/faqs/smart-questions.html.
And if you have read it already, read it again, because you would seem to have missed its
quintessence.

I have just been watching this thread, as the underlying technique is far above my level.
But to answer your claims of arrogance and triteness :

It already took several exchanges to get you to correct the mistakes (or should I say the
chaff?) in your question, which made it close to nonsensical in the first place.
When the persons here who try to help posters in their enquiries asked you for
clarification, your responses seemed to imply that they should have been smart enough to
correct your own messiness, and that you could barely bother yourself to do so.
Even after correction, your original questions were so open-ended that answering them in
the manner you seemed to want, would have amounted to providing a free training manual in
Connector code and the relevant aspects of the Servlet Specification.
But throughout, you sounded as if such an answer was just your due, although you are
neither paying for the software nor for the help. You did not appear to make any effort in
providing information allowing the persons who were trying to help, to at least be able to
focus their explanations and save their time (and yours).
By doing this, you managed to goad someone into spending the time to correct your
misunderstandings and misconceptions, and out of their comprehensive answers you then
magnanimously extracted what was important for you, discarding the rest as chaff and
triteness.
So in the end you got what you probably wanted, and which you could have gotten much
faster, and at less expense of someone else's time, if you had made an effort to write
correct and focused questions in the first place.
In this process, you also managed to expose yourself as an arrogant and egotistical
asshole. I hope that the trade-off is worth it to you.




Attachment: users_231574.ezm (zipped)
andre, i'm sorry if i hurt your feelings and trust in humanity,
try to be positive, try to look on the situation from
another point of view, the one which is not depressive.
i hope my question & answer summary upgraded your level of tomcat understanding.
and that's a good thing, because you wouldn't understand connectors & async servlets
so well, if i didn't post the question in the first place and make the answer summary
in the second. i've already thanked both talkers, which makes me a very nice person :)
and even though slow pid still doesn't understand anything and arrogant mark still
searches for insignificant typos in my posts, i don't blame them for who they are :)
i hope everyone enjoyed the thread. thanks everyone. behave well :)

On 1/28/2012 8:36 PM, André Warnier wrote:
> Hi.
>
> Your original question was
>
> quote
> 1. What are the premises to use either apache.coyote.http11.Http11NioProtocol or org.apache.coyote.http11.Http11NioProtocol
> connectors?
> 2. Do i get any advantages if i use Sync Servlet Api with Http11NioProtocol connector or do i have to use Async Servlet Api to
> get the advantages?
> 3. How do i choose which one to use in any particular case?
> unquote
>
> and your conclusion is :
>
>> well, let's separate the wheat from the chaff and arrogance:
>>
>> 1. nio connector is useful when one needs to handle a lot of
>> client connections, keep-alive ones, for example.
>> 2. async servlet is useful when one app thread can fulfill many responses.
>> 3. communication between connector and async servlet should be called
>> semi-async, rather than async, because request processing is
>> sync anyway, although response processing is async.
>>
>> that could be a simple answer for my question in the first place.
>> everything else is triteness.
>> thanks anyway :)
>> thread can be closed now.
>>
>
> If it were to happen that you would have a further need to make use of this list (or another similar help forum), may I suggest
> that you fist read and ponder the document at http://catb.org/esr/faqs/smart-questions.html.
> And if you have read it already, read it again, because you would seem to have missed its quintessence.
>
> I have just been watching this thread, as the underlying technique is far above my level.
> But to answer your claims of arrogance and triteness :
>
> It already took several exchanges to get you to correct the mistakes (or should I say the chaff?) in your question, which made
> it close to nonsensical in the first place.
> When the persons here who try to help posters in their enquiries asked you for clarification, your responses seemed to imply
> that they should have been smart enough to correct your own messiness, and that you could barely bother yourself to do so.
> Even after correction, your original questions were so open-ended that answering them in the manner you seemed to want, would
> have amounted to providing a free training manual in Connector code and the relevant aspects of the Servlet Specification.
> But throughout, you sounded as if such an answer was just your due, although you are neither paying for the software nor for the
> help. You did not appear to make any effort in providing information allowing the persons who were trying to help, to at least
> be able to focus their explanations and save their time (and yours).
> By doing this, you managed to goad someone into spending the time to correct your misunderstandings and misconceptions, and out
> of their comprehensive answers you then magnanimously extracted what was important for you, discarding the rest as chaff and
> triteness.
> So in the end you got what you probably wanted, and which you could have gotten much faster, and at less expense of someone
> else's time, if you had made an effort to write correct and focused questions in the first place.
> In this process, you also managed to expose yourself as an arrogant and egotistical asshole. I hope that the trade-off is worth
> it to you.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>


Attachment: users_231576.ezm (zipped)
Considering your previous posts, I wasn't really expecting you to take this lying down.
You haven't disappointed me. The world is full of wonders.
"Un paquet de m. dans un bas de soie".
:-)

bxqdev wrote:
> andre, i'm sorry if i hurt your feelings and trust in humanity,
> try to be positive, try to look on the situation from
> another point of view, the one which is not depressive.
> i hope my question & answer summary upgraded your level of tomcat
> understanding.
> and that's a good thing, because you wouldn't understand connectors &
> async servlets
> so well, if i didn't post the question in the first place and make the
> answer summary
> in the second. i've already thanked both talkers, which makes me a very
> nice person :)
> and even though slow pid still doesn't understand anything and arrogant
> mark still
> searches for insignificant typos in my posts, i don't blame them for who
> they are :)
> i hope everyone enjoyed the thread. thanks everyone. behave well :)
>
> On 1/28/2012 8:36 PM, André Warnier wrote:
>> Hi.
>>
>> Your original question was
>>
>> quote
>> 1. What are the premises to use either
>> apache.coyote.http11.Http11NioProtocol or
>> org.apache.coyote.http11.Http11NioProtocol
>> connectors?
>> 2. Do i get any advantages if i use Sync Servlet Api with
>> Http11NioProtocol connector or do i have to use Async Servlet Api to
>> get the advantages?
>> 3. How do i choose which one to use in any particular case?
>> unquote
>>
>> and your conclusion is :
>>
>>> well, let's separate the wheat from the chaff and arrogance:
>>>
>>> 1. nio connector is useful when one needs to handle a lot of
>>> client connections, keep-alive ones, for example.
>>> 2. async servlet is useful when one app thread can fulfill many
>>> responses.
>>> 3. communication between connector and async servlet should be called
>>> semi-async, rather than async, because request processing is
>>> sync anyway, although response processing is async.
>>>
>>> that could be a simple answer for my question in the first place.
>>> everything else is triteness.
>>> thanks anyway :)
>>> thread can be closed now.
>>>
>>
>> If it were to happen that you would have a further need to make use of
>> this list (or another similar help forum), may I suggest
>> that you fist read and ponder the document at
>> http://catb.org/esr/faqs/smart-questions.html.
>> And if you have read it already, read it again, because you would seem
>> to have missed its quintessence.
>>
>> I have just been watching this thread, as the underlying technique is
>> far above my level.
>> But to answer your claims of arrogance and triteness :
>>
>> It already took several exchanges to get you to correct the mistakes
>> (or should I say the chaff?) in your question, which made
>> it close to nonsensical in the first place.
>> When the persons here who try to help posters in their enquiries asked
>> you for clarification, your responses seemed to imply
>> that they should have been smart enough to correct your own messiness,
>> and that you could barely bother yourself to do so.
>> Even after correction, your original questions were so open-ended that
>> answering them in the manner you seemed to want, would
>> have amounted to providing a free training manual in Connector code
>> and the relevant aspects of the Servlet Specification.
>> But throughout, you sounded as if such an answer was just your due,
>> although you are neither paying for the software nor for the
>> help. You did not appear to make any effort in providing information
>> allowing the persons who were trying to help, to at least
>> be able to focus their explanations and save their time (and yours).
>> By doing this, you managed to goad someone into spending the time to
>> correct your misunderstandings and misconceptions, and out
>> of their comprehensive answers you then magnanimously extracted what
>> was important for you, discarding the rest as chaff and
>> triteness.
>> So in the end you got what you probably wanted, and which you could
>> have gotten much faster, and at less expense of someone
>> else's time, if you had made an effort to write correct and focused
>> questions in the first place.
>> In this process, you also managed to expose yourself as an arrogant
>> and egotistical asshole. I hope that the trade-off is worth
>> it to you.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>> For additional commands, e-mail: users-help@(protected)
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>
>



Attachment: users_231573.ezm (zipped)
On 28/01/2012 14:22, Geet Chandra wrote:
> Hi,
>
> My requirements is how to configure *.cer in Tomcat's server.xml file.

You mean you want to set up a connector that uses SSL?


> Actually I don't want to use "keytool -import" command to import the *.cer
> file into *.keystore file.

Any particular reason for your preference?


> Is that possible to use configure *.cer file without using "keytool
> -import" command.

You can configure SSL using either JSSE/keystore or OpenSSL and .crt/.pem.


> Appreciate your help.

You're not really giving us much information to go on. What version of
Tomcat? Java? Operating system?


p


--

[key:62590808]


Attachment: signature.asc (zipped)
Attachment: users_231575.ezm (zipped)
On 28/01/2012 19:07, bxqdev wrote:
> andre, i'm sorry if i hurt your feelings and trust in humanity,
> try to be positive, try to look on the situation from
> another point of view, the one which is not depressive.
> i hope my question & answer summary upgraded your level of tomcat
> understanding.
> and that's a good thing, because you wouldn't understand connectors &
> async servlets
> so well, if i didn't post the question in the first place and make the
> answer summary
> in the second. i've already thanked both talkers, which makes me a very
> nice person :)
> and even though slow pid still doesn't understand anything and arrogant
> mark still
> searches for insignificant typos in my posts, i don't blame them for who
> they are :)
> i hope everyone enjoyed the thread. thanks everyone. behave well :)

LMAO, let's see your garbage collector implementation, then we'll judge.


p


> On 1/28/2012 8:36 PM, André Warnier wrote:
>> Hi.
>>
>> Your original question was
>>
>> quote
>> 1. What are the premises to use either
>> apache.coyote.http11.Http11NioProtocol or
>> org.apache.coyote.http11.Http11NioProtocol
>> connectors?
>> 2. Do i get any advantages if i use Sync Servlet Api with
>> Http11NioProtocol connector or do i have to use Async Servlet Api to
>> get the advantages?
>> 3. How do i choose which one to use in any particular case?
>> unquote
>>
>> and your conclusion is :
>>
>>> well, let's separate the wheat from the chaff and arrogance:
>>>
>>> 1. nio connector is useful when one needs to handle a lot of
>>> client connections, keep-alive ones, for example.
>>> 2. async servlet is useful when one app thread can fulfill many
>>> responses.
>>> 3. communication between connector and async servlet should be called
>>> semi-async, rather than async, because request processing is
>>> sync anyway, although response processing is async.
>>>
>>> that could be a simple answer for my question in the first place.
>>> everything else is triteness.
>>> thanks anyway :)
>>> thread can be closed now.
>>>
>>
>> If it were to happen that you would have a further need to make use of
>> this list (or another similar help forum), may I suggest
>> that you fist read and ponder the document at
>> http://catb.org/esr/faqs/smart-questions.html.
>> And if you have read it already, read it again, because you would seem
>> to have missed its quintessence.
>>
>> I have just been watching this thread, as the underlying technique is
>> far above my level.
>> But to answer your claims of arrogance and triteness :
>>
>> It already took several exchanges to get you to correct the mistakes
>> (or should I say the chaff?) in your question, which made
>> it close to nonsensical in the first place.
>> When the persons here who try to help posters in their enquiries asked
>> you for clarification, your responses seemed to imply
>> that they should have been smart enough to correct your own messiness,
>> and that you could barely bother yourself to do so.
>> Even after correction, your original questions were so open-ended that
>> answering them in the manner you seemed to want, would
>> have amounted to providing a free training manual in Connector code
>> and the relevant aspects of the Servlet Specification.
>> But throughout, you sounded as if such an answer was just your due,
>> although you are neither paying for the software nor for the
>> help. You did not appear to make any effort in providing information
>> allowing the persons who were trying to help, to at least
>> be able to focus their explanations and save their time (and yours).
>> By doing this, you managed to goad someone into spending the time to
>> correct your misunderstandings and misconceptions, and out
>> of their comprehensive answers you then magnanimously extracted what
>> was important for you, discarding the rest as chaff and
>> triteness.
>> So in the end you got what you probably wanted, and which you could
>> have gotten much faster, and at less expense of someone
>> else's time, if you had made an effort to write correct and focused
>> questions in the first place.
>> In this process, you also managed to expose yourself as an arrogant
>> and egotistical asshole. I hope that the trade-off is worth
>> it to you.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>> For additional commands, e-mail: users-help@(protected)
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>


--

[key:62590808]


Attachment: signature.asc (zipped)
Attachment: users_231577.ezm (zipped)
Not good news. I changed every resource statement in server.xml to
something like this:

   <Resource* testOnBorrow="true" validateQuery="SELECT
1"*name="jdbc/xxxxxxx" auth="Container" type="javax.sql.DataSource"
maxActive="100" maxIdle="30" maxWait="10000" removeAbandoned="true"
removeAbandonedTimeout="60" logAbandoned="true" username="xxxxxxxx"
password="xxxxxxxx" driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://127.0.0.1/xxxxxxxx"/>

Zero change. I'm still getting the exact same error message telling me the
connection has expired and I should use autoReconnect to fix it.

First question... is the syntax above correct? (I saw some resource tag
examples that used nested <parameter> tags and other examples that use
attributes on resource tag like above. I couldn't find a definitive
specification to use one over the other. Is the way I have it ok?

Second question.... I like to turn on debug/trace for the connector. But
the connector/j doc lists a ton of parameters for debug, and I don't have a
clue how to set all of them. Can someone just give me a canned config I
can add that'll trace what's going on in the connector?

I'm basically at a loss. If the configuration above is correct, and I'm
still getting expired connections, I don't know what else to do. If indeed
TC 7 changed from round-robin to LIFO, it might explain why it started
hitting stale connections. But that still doesn't explain why
testOnBorrow, validateQuery, and autoReconnect=true don't seem to do
anything on stale connections.

Maybe with some logging and tracing, something will become obvious.

Thx.

Jerry

Attachment: users_231578.ezm (zipped)
Answers and comments are inline (mostly).

----- Original Message -----

> From: Jerry Malcolm <2ndgenfilms@(protected)>
> To: Tomcat Users List <users@(protected)>
> Cc:
> Sent: Saturday, January 28, 2012 5:32 PM
> Subject: Re: connection autoReconnect?
>
> Not good news.  I changed every resource statement in server.xml to
> something like this:
>
>       <Resource* testOnBorrow="true" validateQuery="SELECT
> 1"*name="jdbc/xxxxxxx" auth="Container"
> type="javax.sql.DataSource"
> maxActive="100" maxIdle="30" maxWait="10000"
> removeAbandoned="true"
> removeAbandonedTimeout="60" logAbandoned="true"
> username="xxxxxxxx"
> password="xxxxxxxx" driverClassName="com.mysql.jdbc.Driver"
> url="jdbc:mysql://127.0.0.1/xxxxxxxx"/>
> 

Hopefully the asterisks in your Resource element (<Resource* and *name
are artifacts of your copy and paste. If they're in server.xml, I don't
know if Tomcat would even start. If Tomcat does start, it will probably ignore
malformed XML elements. Check your log files for such messages.
> Zero change.  I'm still getting the exact same error message telling me the
> connection has expired and I should use autoReconnect to fix it.
>
> First question... is the syntax above correct?  (I saw some resource tag
> examples that used nested  <parameter> tags and other examples that use
> attributes on resource tag like above.  I couldn't find a definitive
> specification to use one over the other.  Is the way I have it ok?


When in doubt, always follow the documentation on the Apache Tomcat
site.

From the documentation:

No components may be nested inside a Resources element

So any documentation that you've read which specifies <parameter> inside
of a Resource element is wrong.
> Second question.... I like to turn on debug/trace for the connector.  But
> the connector/j doc lists a ton of parameters for debug, and I don't have a
> clue how to set all of them.  Can someone just give me a canned config I
> can add that'll trace what's going on in the connector?
>
> I'm basically at a loss.  If the configuration above is correct, and I'm
> still getting expired connections, I don't know what else to do.  If indeed
> TC 7 changed from round-robin to LIFO, it might explain why it started
> hitting stale connections.  But that still doesn't explain why
> testOnBorrow, validateQuery, and autoReconnect=true don't seem to do
> anything on stale connections.
>

I've had nothing but trouble with autoReconnect="true".

> Maybe with some logging and tracing, something will become obvious.
>
> Thx.
>
> Jerry


OK, here's a formatted version of your configuration:

<Resource
testOnBorrow="true"
validateQuery="SELECT 1"
name="jdbc/xxxxxxx"
auth="Container"
type="javax.sql.DataSource"
maxActive="100"
maxIdle="30"
maxWait="10000"
removeAbandoned="true"
removeAbandonedTimeout="60"
logAbandoned="true"
username="xxxxxxxx"
password="xxxxxxxx"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://127.0.0.1/xxxxxxxx"/>

Reordering it so that it follows along with the documentation and adding
the defaults where you've not specified leads to:

<Resource
name="jdbc/xxxxxxx"
auth="Container"
type="javax.sql.DataSource"
driverClassName="com.mysql.jdbc.Driver"
username="xxxxxxxx"
password="xxxxxxxx"
url="jdbc:mysql://127.0.0.1/xxxxxxxx"
initialSize="0"
maxActive="100"
minIdle="0"
maxIdle="30"
maxWait="10000"
validationQuery="SELECT 1"
validationQueryTimeout="-1"
testOnBorrow="true"
testOnReturn="false"
removeAbandoned="true"
removeAbandonedTimeout="60"
logAbandoned="true" />
There are a number of things to note here.

You did not set the initialSize value. By default it is 0. This means
that there are no initial connections to the database.

You did not set the minIdle value. By default, it is 0. This means that
if all of your connections are idle, the pool can shrink to 0.

The correct parameter to specify a validation query is validationQuery.
validateQuery is not correct, and should be ignored. You should see a
warning to that effect in your catalina.out logs.

So, I'm guessing that if you use your Resource element with a DataSource
Realm, something like the following might happen. I'm speculating here
since I've not looked at this part of the code.

1. Tomcat starts up and complains about validateQuery
2. A pool is created with NO active connections
3. You use a form-based login and a DataSource Realm to authenticate
4. The DataSource Realm asks the Resource ( via a JNDI name) for a data source
5. The pool says - I don't have one, but I'll create one
6. You have a testOnBorrow="true" so the pool will use the validation query
7. The pool does not have a validation query to run (see notes above)
8. The default time out for a validation query is -1 - infinite
9. The pool never returns

That's my guess.

Either that, or the pool sees that there is no validation query and
returns immediately with no database connection since there is nothing
in the pool to start with and the pool could not perform a validation query.

I would do the following:

1. Fix initialSize and set it to some reasonable number

A reasonable number depends on your application and your application's
usage.

2. Fix minIdle and set it to some reasonable number

A reasonable number depends on your application and your application's
usage.

3. Fix validateQuery to be validationQuery

Monitor the connections.

On the MySQL side you can use MySQL workbench if you don't wish to use
the command line client. I believe the command is SHOW PROCESSLIST; in 
the command line client

You can monitor the number of connections with JMX on the Tomcat side.

. . . . just my two cents.
/mde/

PS - You do not have to cc: me when you send to the list. All that means
is I get two copies of the email.



Attachment: users_231579.ezm (zipped)
I'm running tomcat 6 behind apache.

I currently have an application deployed as "myApplication" and it is
available at "http://www.mydomain.com/myApplication".

How can I make this application available at "http://www.mydomain.com"
without deploying it as ROOT.war?

My server is running Ubuntu 10.04.

Thanks!

Dean Del Ponte

Attachment: users_231580.ezm (zipped)
> From: Dean Del Ponte [mailto:dean.delponte@(protected)]
> Subject: Tomcat 6 - How to make an application available at www.mydomain.com

> How can I make this application available at "http://www.mydomain.com"
> without deploying it as ROOT.war?

Just save yourself much grief and go ahead and deploy it as ROOT.war - follow best practice.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.



Attachment: users_231581.ezm (zipped)
> I'm running tomcat 6 behind apache.
>
> I currently have an application deployed as "myApplication" and it is
> available at "http://www.mydomain.com/myApplication".
>
> How can I make this application available at "http://www.mydomain.com"
> without deploying it as ROOT.war?
>
> My server is running Ubuntu 10.04.
>
> Thanks!
>
> Dean Del Ponte
>

You could use a rewrite rule to achieve that:

RewriteEngine On
RewriteRule ^/$ /myApplication/ [PT]
JkMount /myApplication* tomcat

Works for me very well.

Thomas



Attachment: users_231582.ezm (zipped)
Hi,

the best way is to deploy your application to run inside tomcat
without a context path - eg. to be available at http://localhost:8080/
instead of http://localhost:8080/myApplication and use your apache
reverse proxying / virtual host as it is.

Trying to strip application context in virtual host configuration in
my expirience was troublesome in some of my expiriences and now I
always try to avoid it.

What do you mean exactly by "without deploying it as ROOT.war"?

You can set the context path of your Tomcat deployed applications to
whatever you want - context path doesn't have to be the same as .war
archive name. Just stop using deployment trough webapps directory and
start using context files inside tomcat-x.x.x/conf directory to define
your applications (all explained here
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html ), for
example:

1. Make a file called
${catalina.base}/conf/Catalina/localhost.ROOT.xml that contains:

<?xml version='1.0' encoding='utf-8'?>
<Context docBase="${catalina.base}/war/myApplication.war" path="">
<Manager pathname=""/>
</Context>

2. Copy you myApplication.war to ${catalina.base}/war - or some other
directory if you want to arange things differently.

3. Remove myApplication.war from ${catalina.base}/webapps

Where ${catalina.base} is you current tomcat installation (or base
instance) where you are currently deploying you app.



On 1/29/12, Thomas Rohde <tro@(protected):
>> I'm running tomcat 6 behind apache.
>>
>> I currently have an application deployed as "myApplication" and it is
>> available at "http://www.mydomain.com/myApplication".
>>
>> How can I make this application available at "http://www.mydomain.com"
>> without deploying it as ROOT.war?
>>
>> My server is running Ubuntu 10.04.
>>
>> Thanks!
>>
>> Dean Del Ponte
>>
>
> You could use a rewrite rule to achieve that:
>
> RewriteEngine On
> RewriteRule ^/$ /myApplication/ [PT]
> JkMount /myApplication* tomcat
>
> Works for me very well.
>
> Thomas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>
>


--
Why?
Because YES!


Attachment: users_231583.ezm (zipped)
Just a small correction:

1. Make a file called
${catalina.base}/conf/Catalina/localhost/ROOT.xml that contains:

instead of

1. Make a file called
${catalina.base}/conf/Catalina/localhost.ROOT.xml that contains:

On 1/29/12, Borut Hadžialić <borut.hadzialic@(protected):
> Hi,
>
> the best way is to deploy your application to run inside tomcat
> without a context path - eg. to be available at http://localhost:8080/
> instead of http://localhost:8080/myApplication and use your apache
> reverse proxying / virtual host as it is.
>
> Trying to strip application context in virtual host configuration in
> my expirience was troublesome in some of my expiriences and now I
> always try to avoid it.
>
> What do you mean exactly by "without deploying it as ROOT.war"?
>
> You can set the context path of your Tomcat deployed applications to
> whatever you want - context path doesn't have to be the same as .war
> archive name. Just stop using deployment trough webapps directory and
> start using context files inside tomcat-x.x.x/conf directory to define
> your applications (all explained here
> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html ), for
> example:
>
> 1. Make a file called
> ${catalina.base}/conf/Catalina/localhost.ROOT.xml that contains:
>
> <?xml version='1.0' encoding='utf-8'?>
> <Context docBase="${catalina.base}/war/myApplication.war" path="">
> <Manager pathname=""/>
> </Context>
>
> 2. Copy you myApplication.war to ${catalina.base}/war - or some other
> directory if you want to arange things differently.
>
> 3. Remove myApplication.war from ${catalina.base}/webapps
>
> Where ${catalina.base} is you current tomcat installation (or base
> instance) where you are currently deploying you app.
>
>
>
> On 1/29/12, Thomas Rohde <tro@(protected):
>>> I'm running tomcat 6 behind apache.
>>>
>>> I currently have an application deployed as "myApplication" and it is
>>> available at "http://www.mydomain.com/myApplication".
>>>
>>> How can I make this application available at "http://www.mydomain.com"
>>> without deploying it as ROOT.war?
>>>
>>> My server is running Ubuntu 10.04.
>>>
>>> Thanks!
>>>
>>> Dean Del Ponte
>>>
>>
>> You could use a rewrite rule to achieve that:
>>
>> RewriteEngine On
>> RewriteRule ^/$ /myApplication/ [PT]
>> JkMount /myApplication* tomcat
>>
>> Works for me very well.
>>
>> Thomas
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>> For additional commands, e-mail: users-help@(protected)
>>
>>
>
>
> --
> Why?
> Because YES!
>


--
Why?
Because YES!

©2008 junlu.com - Jax Systems, LLC, U.S.A.