date:20120128




On 1/28/2012 6:33 AM, Terence M. Bandoian wrote:



How much is a lot?


10'000/sec


How many Tomcats are you running?


1


How much RAM/CPU per server etc?


8GB/Xeon


How big is the average response?


300Kb



How many NICs do you have? Have fast are they?


one. as i said above, the actual traffic is less than 1Gb/sec.
don't pay attention to technical details of my hardware.
the question is theoretical.
i want to understand what each combination of connector+servlet api is intended 
for.
my service works pretty well, i'm just looking forward, but most repliers don't 
know
the subject well, so they can't explain.



-Terence Bandoian


-
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: Connectors: Http11Protocol vs. Http11NioProtocol




On 1/28/2012 12:09 PM, Pid * wrote:

On 27 Jan 2012, at 23:53, bxqdevbxq...@themailbay.com  wrote:



On 1/28/2012 3:41 AM, Pid wrote:

On 27/01/2012 23:35, bxqdev wrote:



On 1/28/2012 3:16 AM, Pid wrote:

On 27/01/2012 22:51, bxqdev wrote:



On 1/28/2012 2:39 AM, Pid wrote:

On 27/01/2012 21:35, bxqdev wrote:



On 1/28/2012 1:16 AM, Pid wrote:

On 27/01/2012 21:06, bxqdev wrote:



On 1/27/2012 8:27 PM, Pid wrote:

On 27/01/2012 14:53, bxqdev wrote:

Hello, Developers!

1. What are the premises to use either
apache.coyote.http11.Http11NioProtocol or
org.apache.coyote.http11.Http11NioProtocol connectors?


Eh?  Is that what you really mean?


i mean what are the reasons to use either connector variant.


NIO can handle more concurrent connections.


yeah, that's why i use the nio connector.




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?


What advantages are you looking for?  How much traffic are you
expecting
to handle?


a lot of. i'm looking for advantages in throughput and performance,
for
example.


How much is a lot?


10'000/sec


How many Tomcats are you running?


1


How much RAM/CPU per server etc?


8GB/Xeon


Only 1 CPU?


yes, but it's multicore.




How big is the average response?


300Kb


So you want to send 300k * 1 / sec?  Isn't that just under 3Gb per
second?


actually when i measured it was less than 1Gb/sec


I see.  Did you identify where the bottleneck was?


well, we are getting too far from the subject.
can you make up 3 cases when to use 3 combinations of connector+servlet api
1. bio connector + async servlet
2. nio connector + sync servlet
3. nio connector + async servlet
i mean in which theoretical case each combination of connector+servlet
api is the best choice?


Nope.


it's not that hard, when you know the subject, but i guess, unfortunately, it's 
not the case :)


Oh, that's even more crude than my baiting. Aside from which Mark
already gave a reasonable answer.


well, nothing personal. but if you can't explain - you don't know by yourself. 
that's the rule :)




3. How do i choose which one to use in any particular case?


First, don't prematurely optimise.  Have you tested your
application
yet?


yes, i need a better throughput and performance.


Please provide details.

How have you optimised your application so far, or are you hoping to
optimise Tomcat first?


webapp is optimized, i want to optimize tomcat.


How did you optimise your webapp for 3Gb/sec with only 8Gb of RAM?


i wrote nice code. it's serving 1Gb/sec with 8Gb of RAM. are you
surprised?


No, I'm curious*.  Of course you mean8Gb for the JVM process, as the
OS etc consumes ~1.5Gb usually, you want to leave a bit of space too, so
usually end up aiming for 4Gb for the JVM unless you want to use swap as
well.

Are you using swap to improve your memory performance?


is it some kind of sarcasm?


Yep.


ok, very funny.


In 3 seconds you'll have produced more data than you have RAM, how have
you optimised the garbage collector for this?


we use a custom garbage collector.


Interesting.  Of your own design?


yes, we're going to opensource it soon. stay tuned.


I shall.


what garbage collector do you use?


Depends.


ok. can you enumerate them though? are you able to give detailed and 
comprehensive
answers, besides yeps, nopes and depends?




p


I was going to ask whether you had a 64bit JVM and whether you found
CompressedOops to be a performance improvement or not?


why would we use 32bit OS/JVM on 8Gb server?
actually we don't have any problems to solve.
my question is more theoretical.


* There's a few meanings to that, André, I know which one I meant.


-
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



-
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: Connectors: Http11Protocol vs. Http11NioProtocol

2012-01-28 Thread Mark Thomas

On 27/01/2012 23:16, bxqdev wrote:
 2. async servlet api is not much usefull for servers, with nio
 connectors (tomcat-7). at least you can't image the case.

 I don't say that. In fact, I said exactly the opposite.
 
 well, then what's the case to use both of this technologies? can you
 make up a theoretical case for an example?

Yes. See below.

 3. async servlet api is some general technology to decouple client from
 server, when server doesn't have nio connector (server is bio-only).

 No. The Servlet Async API and the considerations for when one might use
 it are completely orthogonal to connector selection.
 
 how is that? both connector and servlet process user http request. one
 by one. how are they orthogonal?

The Servlet API, including the Async API only provides blocking IO.

I will ignore the APR/native connector since that just complicates
things further and just consider the BIO and NIO connectors below.

The fundamental difference is that BIO requires one thread per
connection whereas NIO requires one thread per currently processing
request plus a few threads for the pollers. Each poller can monitor
several thousand connections.

Therefore in a situation where you have many more connections than you
have current requests (think lots of HTTP keep-alive) then NIO scales
significantly better than BIO. The (very small) price you pay is
performance since using a poller adds overhead to request processing.

[1] shows that the NIO connector uses non-blocking IO where it can but
as soon as it enters the realm of the Servlet API (reading the request
body and writing the request response) it has to simulate blocking IO.

There is actually a complication to BIO in newer versions of Tomcat.
Rather than dedicating one thread to a connection, each time Tomcat
needs to read from a connection (remember this is blocking IO and there
might not be anything to read if the connection is in keep-alive but the
thread will then block until some data turns up or the connection times
out) Tomcat obtains a thread from an executor. This raises the
possibility of having more connections than you have threads. With BIO
that is usually bad and results in unexpected delays in processing
requests but as we'll see shortly, there are times (not many) where it
might be useful.


Prior to the Servlet 3.0 Async API a single container thread was
responsible for all of the processing associated with a request.

A few points to note at this point:
- All IO is still blocking IO
- The async API is only for writing data to the response. There is no
async reading of data from the client.

A typical usage of the Servlet 3.0 Async API is as follows:
- request processing starts as usual on a container thread
- async is started
- the container thread is returned to the container's thread pool
- processing continues on an application thread
- the application writes some data to the response
- the application passes the response back to the container for the
container to finish it off on a container thread

The purpose of the Servlet 3.0 Async API is to remove the one thread per
currently processing request constraint.

This allows applications to do things like:
- implement a stock ticker with one thread writing to many responses
(rather than one thread per response)
- implement a chat program with one thread writing to all the clients
(rather than one thread per response)

If applications relay on external resources that are known to take a
long time to respond, prior to the Async API developers had no choice
but to simply block waiting for the external resource to respond. With
the Async API, a single thread can monitor an external resource on
behalf of many requests and only dispatch the request/response pair to a
container thread for processing when the external resource has replied.
This allows for more efficient use of container threads.

Now back to the BIO complication. Lets say you have 100 container
threads configured on your BIO connector and you are absolutely sure
that at any one time 20% of your incoming connections would be using
Servlet 3 Async and would be being handled by an application thread then
you could set maxConnections to 120 and service 120 users in parallel.
Your assumption regarding the 20% was wrong then you would see
potentially long delays in processing incoming requests as connections
with data were waiting for a container thread to become available to
process it.


So back to my original point. BIO vs NIO and Servlet 3 Sync vs Async are
solving orthogonal problems.

If you use an NIO connector that doesn't help you write a chat
application more efficiently. You would still need one thread per
client. For that you need the Servlet 3.0 Async API.

The Async API does not help you efficiently handle many thousands of
connections when the majority of them are in HTTP keep-alive. For that
you need the NIO connector.

Different problems, different solutions.

 I am getting rather bored with this. Please go and

Re: Connectors: Http11Protocol vs. Http11NioProtocol

On 28/01/2012 09:07, bxqdev wrote:

snip

 I see.  Did you identify where the bottleneck was?

 well, we are getting too far from the subject.
 can you make up 3 cases when to use 3 combinations of
 connector+servlet api
 1. bio connector + async servlet
 2. nio connector + sync servlet
 3. nio connector + async servlet
 i mean in which theoretical case each combination of connector+servlet
 api is the best choice?

 Nope.

 it's not that hard, when you know the subject, but i guess,
 unfortunately, it's not the case :)

 Oh, that's even more crude than my baiting. Aside from which Mark
 already gave a reasonable answer.
 
 well, nothing personal. but if you can't explain - you don't know by
 yourself. that's the rule :)

Still baiting, still not biting.

I might refer to your own replies, in which you made certain claims
without explaining how.


 3. How do i choose which one to use in any particular case?

 First, don't prematurely optimise.  Have you tested your
 application
 yet?

 yes, i need a better throughput and performance.

 Please provide details.

snip

 yes, we're going to opensource it soon. stay tuned.

 I shall.

 what garbage collector do you use?

 Depends.
 
 ok. can you enumerate them though? are you able to give detailed and
 comprehensive
 answers, besides yeps, nopes and depends?

Yep.


p



-- 

[key:62590808]



signature.asc
Description: OpenPGP digital signature

Re: Connectors: Http11Protocol vs. Http11NioProtocol


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.

On 1/28/2012 3:59 PM, Mark Thomas wrote:

On 27/01/2012 23:16, bxqdev wrote:

2. async servlet api is not much usefull for servers, with nio
connectors (tomcat-7). at least you can't image the case.


I don't say that. In fact, I said exactly the opposite.


well, then what's the case to use both of this technologies? can you
make up a theoretical case for an example?


Yes. See below.


3. async servlet api is some general technology to decouple client from
server, when server doesn't have nio connector (server is bio-only).


No. The Servlet Async API and the considerations for when one might use
it are completely orthogonal to connector selection.


how is that? both connector and servlet process user http request. one
by one. how are they orthogonal?


The Servlet API, including the Async API only provides blocking IO.

I will ignore the APR/native connector since that just complicates
things further and just consider the BIO and NIO connectors below.

The fundamental difference is that BIO requires one thread per
connection whereas NIO requires one thread per currently processing
request plus a few threads for the pollers. Each poller can monitor
several thousand connections.

Therefore in a situation where you have many more connections than you
have current requests (think lots of HTTP keep-alive) then NIO scales
significantly better than BIO. The (very small) price you pay is
performance since using a poller adds overhead to request processing.

[1] shows that the NIO connector uses non-blocking IO where it can but
as soon as it enters the realm of the Servlet API (reading the request
body and writing the request response) it has to simulate blocking IO.

There is actually a complication to BIO in newer versions of Tomcat.
Rather than dedicating one thread to a connection, each time Tomcat
needs to read from a connection (remember this is blocking IO and there
might not be anything to read if the connection is in keep-alive but the
thread will then block until some data turns up or the connection times
out) Tomcat obtains a thread from an executor. This raises the
possibility of having more connections than you have threads. With BIO
that is usually bad and results in unexpected delays in processing
requests but as we'll see shortly, there are times (not many) where it
might be useful.


Prior to the Servlet 3.0 Async API a single container thread was
responsible for all of the processing associated with a request.

A few points to note at this point:
- All IO is still blocking IO
- The async API is only for writing data to the response. There is no
async reading of data from the client.

A typical usage of the Servlet 3.0 Async API is as follows:
- request processing starts as usual on a container thread
- async is started
- the container thread is returned to the container's thread pool
- processing continues on an application thread
- the application writes some data to the response
- the application passes the response back to the container for the
container to finish it off on a container thread

The purpose of the Servlet 3.0 Async API is to remove the one thread per
currently processing request constraint.

This allows applications to do things like:
- implement a stock ticker with one thread writing to many responses
(rather than one thread per response)
- implement a chat program with one thread writing to all the clients
(rather than one thread per response)

If applications relay on external resources that are known to take a
long time to respond, prior to the Async API developers had no choice
but to simply block waiting for the external resource to respond. With
the Async API, a single thread can monitor an external resource on
behalf of many requests and only dispatch the request/response pair to a
container thread for processing when the external resource has replied.
This allows for more efficient use of container threads.

Now back to the BIO complication. Lets say you have 100 container
threads configured on your BIO connector and you are absolutely sure
that at any one time 20% of your incoming connections would be using
Servlet 3 Async and would be being handled by an application thread then
you could set maxConnections to 120 and service 120 users in parallel.
Your assumption regarding the 20% was wrong then you would see
potentially long delays in processing incoming requests as connections
with data were waiting

Re: Connectors: Http11Protocol vs. Http11NioProtocol




On 1/28/2012 5:01 PM, Pid wrote:

On 28/01/2012 09:07, bxqdev wrote:

snip


I see.  Did you identify where the bottleneck was?


well, we are getting too far from the subject.
can you make up 3 cases when to use 3 combinations of
connector+servlet api
1. bio connector + async servlet
2. nio connector + sync servlet
3. nio connector + async servlet
i mean in which theoretical case each combination of connector+servlet
api is the best choice?


Nope.


it's not that hard, when you know the subject, but i guess,
unfortunately, it's not the case :)


Oh, that's even more crude than my baiting. Aside from which Mark
already gave a reasonable answer.


well, nothing personal. but if you can't explain - you don't know by
yourself. that's the rule :)


Still baiting, still not biting.

I might refer to your own replies, in which you made certain claims
without explaining how.


you're trying to change the subject, the point is: you don't know enough to
answer the original question.





3. How do i choose which one to use in any particular case?


First, don't prematurely optimise.  Have you tested your
application
yet?


yes, i need a better throughput and performance.


Please provide details.


snip


yes, we're going to opensource it soon. stay tuned.


I shall.


what garbage collector do you use?


Depends.


ok. can you enumerate them though? are you able to give detailed and
comprehensive
answers, besides yeps, nopes and depends?


Yep.


unfortunately you've just proved the opposite :)




p





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ThreadLocals, context listeners and classloader leaks

On 26.01.2012 18:00, Jess Holle wrote:

On 1/26/2012 10:38 AM, Mark Thomas wrote:

OK. ThreadLocals have no place in a web application. Period. If a
programmer insists on using them, then it is their responsibility to
clean up the mess they leave behind.

Tomcat's memory leak detection and prevention code goes some way to
clearing up things like this but it is never going to cover every case.

Mark

Or put another way, you have a choice:

1. Use ThreadLocals the way you'd have assumed you could, but don't
expect to ever restart your web app without leaking tons of memory.
2. Use ThreadLocals, but be sure you religiously clean up after
yourself by the time your web app is fully shut down.
3. Don't use ThreadLocals.

If you use someone else's library that uses ThreadLocals then you'll
probably end up in forced into A.

That said, there could and arguably should be another choice:

4. Select a special mode in a servlet engine that shuts down all
threads that have ever serviced requests for a given web app when it
is shutdown (and code your web app to shutdown any threads it
creates, obviously!), e.g. after they complete servicing any request
in progress. [It could just replace all request threads with new
ones after the requests currently in progress complete.]

That's assuming the servlet engine is nice enough to provide such a
mode. If it did, however, I believe that would resolve any ThreadLocal
issues without one having to avoid using a perfect natural and useful
Java language feature. I'd argue all servlet engines should really
provide this feature for just this reason. That said, I can live with A.

Renewing threads is what was implemented some time ago in Tomcat's
ThreadLocal leak prevention:

http://tomcat.apache.org/tomcat-7.0-doc/config/listeners.html#ThreadLocal_Leak_Prevention_Listener_-_org.apache.catalina.core.ThreadLocalLeakPreventionListener

Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] Inspecting JMX


On 26.01.2012 19:32, Christopher Schultz wrote:


Now I'm trying to get similar information using a command-line tool
that is very simple called check_jmx -- it's a plug-in for Nagios. It
appears that this tool does not support the attach API and so it
looks like I'll have to enable remote JMX, so I've followed the
instructions on Tomcat's monitoring page to enable remote JMX [3]:




3. Should I just give up and use the manager app's jmxproxy? I don't
currently deploy the manager app, and I'd like to avoid doing that
if possible. But, it may be a slightly cleaner solution.

4. Should I hack the code for check_jmx to use the Attach API and
try to avoid all of this stupid port business? Getting the PID
of the Tomcat process shouldn't be hard as long as I use
CATALINA_PID and get the value from there.


Note that the naive check_jmx attempt will not scale. Monitoring JVMs 
using JMX by starting a new JVM on the polling server for each poll and 
each monitored instance will soon killk your monitoring server.


You either need to use an agent running in the target JVM and providing 
access via a simpler non-Java protocol, or you need a long running Java 
based gateway, which does the JMX communication with the target JVMs and 
gets itself queried with something simpler.


In that sense the Tomcat Manager can act as an agent via its jmxproxy 
feature, making JMX data available for each HTTP client that can parse 
simle text output.


Another a bit more sophisticated approach which can be well integrated 
with Nagios is Jmx4Perl as a client in combination with Jolikia as the 
agent (all Open Source).


Of course there are many more options available.

Regards,

Rainer


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Path of log files changed in Tomcat 7.0.25 when installing as Windows Service


On 28.01.2012 07:27, Caldarale, Charles R wrote:

From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Subject: RE: Path of log files changed in Tomcat 7.0.25 when installing as 
Windows Service



Haven't yet figured out why the ${catalina.base} references
in logging.properties aren't getting resolved.


It appears that procrun 1.0.8 is broken: ++JvmOptions is being treated like 
--JvmOptions, so the settings of catalina.base and catalina.home in service.bat 
are getting lost.


Chuck opened an issue:

https://issues.apache.org/bugzilla/show_bug.cgi?id=52548

Regards,

Rainer


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Connectors: Http11Protocol vs. Http11NioProtocol

2012-01-28 Thread Pid *

On 28 Jan 2012, at 13:34, bxqdev bxq...@themailbay.com wrote:

 On 1/28/2012 5:01 PM, Pid wrote:
 On 28/01/2012 09:07, bxqdev wrote:

 snip

 I see.  Did you identify where the bottleneck was?

 well, we are getting too far from the subject.
 can you make up 3 cases when to use 3 combinations of
 connector+servlet api
 1. bio connector + async servlet
 2. nio connector + sync servlet
 3. nio connector + async servlet
 i mean in which theoretical case each combination of connector+servlet
 api is the best choice?

 Nope.

 it's not that hard, when you know the subject, but i guess,
 unfortunately, it's not the case :)

 Oh, that's even more crude than my baiting. Aside from which Mark
 already gave a reasonable answer.

 well, nothing personal. but if you can't explain - you don't know by
 yourself. that's the rule :)

 Still baiting, still not biting.

 I might refer to your own replies, in which you made certain claims
 without explaining how.

 you're trying to change the subject, the point is: you don't know enough to
 answer the original question.

 3. How do i choose which one to use in any particular case?

 First, don't prematurely optimise.  Have you tested your
 application
 yet?

 yes, i need a better throughput and performance.

 Please provide details.

 snip

 yes, we're going to opensource it soon. stay tuned.

 I shall.

 what garbage collector do you use?

 Depends.

 ok. can you enumerate them though? are you able to give detailed and
 comprehensive
 answers, besides yeps, nopes and depends?

 Yep.

 unfortunately you've just proved the opposite :)

Your reasoning is flawed and my contributions to this list over the
years stand as evidence to the contrary.

Do let us know when you open source your garbage collector.


p

 -
 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

How to configure certificate file (*.cer) in Tomcat 6

2012-01-28 Thread Geet Chandra

Hi,

My requirements is how to configure *.cer in Tomcat's server.xml file.

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

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

Appreciate your help.

-- 
Thanks  Regards
Geet

Re: TC7 very slow SessionIdGenerator SecureRandom initialization

On 28.01.2012 00:38, Pid wrote:

On 27/01/2012 23:25, Caldarale, Charles R wrote:

From: David Rees [mailto:dree...@gmail.com]
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-devm=130182757504685w=2

http://search.oracle.com/search/search?search_p_main_operator=allstart=1group=bugs.sun.comq=%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 :(.

Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Path of log files changed in Tomcat 7.0.25 when installing as Windows Service

2012-01-28 Thread Konstantin Preißer

Hi,

 -Original Message-
 From: Rainer Jung [mailto:rainer.j...@kippdata.de]
 Sent: Saturday, January 28, 2012 3:00 PM
 To: users@tomcat.apache.org
 Subject: Re: Path of log files changed in Tomcat 7.0.25 when installing
 as Windows Service

 On 28.01.2012 07:27, Caldarale, Charles R wrote:
  From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
  Subject: RE: Path of log files changed in Tomcat 7.0.25 when
 installing as Windows Service

  Haven't yet figured out why the ${catalina.base} references
  in logging.properties aren't getting resolved.

  It appears that procrun 1.0.8 is broken: ++JvmOptions is being
 treated like --JvmOptions, so the settings of catalina.base and
 catalina.home in service.bat are getting lost.

 Chuck opened an issue:

 https://issues.apache.org/bugzilla/show_bug.cgi?id=52548

 Regards,

 Rainer

Thanks to all!

Best Regards,

Konstantin Preißer 

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Connectors: Http11Protocol vs. Http11NioProtocol




On 1/28/2012 6:14 PM, Pid * wrote:

On 28 Jan 2012, at 13:34, bxqdevbxq...@themailbay.com  wrote:


On 1/28/2012 5:01 PM, Pid wrote:

On 28/01/2012 09:07, bxqdev wrote:

snip


I see.  Did you identify where the bottleneck was?


well, we are getting too far from the subject.
can you make up 3 cases when to use 3 combinations of
connector+servlet api
1. bio connector + async servlet
2. nio connector + sync servlet
3. nio connector + async servlet
i mean in which theoretical case each combination of connector+servlet
api is the best choice?


Nope.


it's not that hard, when you know the subject, but i guess,
unfortunately, it's not the case :)


Oh, that's even more crude than my baiting. Aside from which Mark
already gave a reasonable answer.


well, nothing personal. but if you can't explain - you don't know by
yourself. that's the rule :)


Still baiting, still not biting.

I might refer to your own replies, in which you made certain claims
without explaining how.


you're trying to change the subject, the point is: you don't know enough to
answer the original question.


3. How do i choose which one to use in any particular case?


First, don't prematurely optimise.  Have you tested your
application
yet?


yes, i need a better throughput and performance.


Please provide details.


snip


yes, we're going to opensource it soon. stay tuned.


I shall.


what garbage collector do you use?


Depends.


ok. can you enumerate them though? are you able to give detailed and
comprehensive
answers, besides yeps, nopes and depends?


Yep.


unfortunately you've just proved the opposite :)


Your reasoning is flawed and my contributions to this list over the
years stand as evidence to the contrary.


contribution of unrelated counter-questions to unanswered questions :)
thanks anyway, at least you've tried :)



Do let us know when you open source your garbage collector.



sure!



p


-
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: Catching Exception in Application

2012-01-28 Thread Jonathan Rosenberg

On Fri, Jan 27, 2012 at 6:46 PM, Terence M. Bandoian tere...@tmbsw.com wrote:
  On 1:59 PM, Pid wrote:

 On 27/01/2012 18:53, Jonathan Rosenberg wrote:

 On Fri, Jan 27, 2012 at 1:45 PM, Pidp...@pidster.com  wrote:

 On 27/01/2012 18:38, Jonathan Rosenberg wrote:

 That is in the original CAS server web.xml.  I left it untouched.

 For the rest of the day, as an experiment I will bottom-post to any
 thread containing a reply via top-post.


 On Fri, Jan 27, 2012 at 1:35 PM, Pidp...@pidster.com  wrote:

 On 27/01/2012 18:00, Jonathan Rosenberg wrote:

 Vital stats:

 Apache Tomcat/7.0.22  1.6.0_20-b20    Sun Microsystems Inc.   Linux
       2.6.34.7-56.40.amzn1.i686

 I have a CAS server deployed on this instance.

 I am trying to catch errors within the server (e.g., DB down) so I
 can
 display friendly page to user  log error.


 In the web.xml for the CAS server I have (I added error-page for
 java.lang.Exception, ohters were already there)

 error-page

 exception-typeorg.springframework.context.ApplicationContextException/exception-type

 location/WEB-INF/view/jsp/brokenContext.jsp/location
       /error-page

       error-page
               exception-typejava.lang.Exception/exception-type
               location/WEB-INF/view/jsp/exception.jsp/location
       /error-page

       error-page
         error-code500/error-code
               location/WEB-INF/view/jsp/errors.jsp/location
       /error-page

       error-page
               error-code404/error-code
               location//location
       /error-page

 Is the above correct?  A 404 returns '/'?


 p

     error-page
         error-code403/error-code
         location/403.html/location
     /error-page

 Bu when I trigger an error (i.e., stop DB) I am seeing the default
 Tomcat error page:

 HTTP Status 500 -
 type Exception report
 message
 description The server encountered an internal error () that
 prevented
 it from fulfilling this request.
 exception
 org.springframework.webflow.execution.ActionExecutionException:
 Exception thrown executing [AnnotatedAction@17b2b99 targetAction =
 [EvaluateAction@16b653d expression =
 authenticationViaFormAction.submit(flowRequestContext,
 flowScope.credentials, messageContext), resultExpression = [null]],
 attributes = map[[empty]]] in state 'realSubmit' of flow 'login' --
 action execution attributes were 'map[[empty]]'
 . . .

 I'm a newbie to Tomcat  am not sure where to start looking.

 --
 Jonathan Rosenberg
 Founder  Executive Director

 Tabby's Place, a Cat Sanctuary
 http://www.tabbysplace.org/

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


 --

 [key:62590808]

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

 Did you post the whole error page definition block?
 What was the original contents and what have you added?

 Original error-page elements:

        error-page

  exception-typeorg.springframework.context.ApplicationContextException/exception-type
                location/WEB-INF/view/jsp/brokenContext.jsp/location
        /error-page

        error-page
                exception-typejava.lang.Exception/exception-type
                location/WEB-INF/view/jsp/exception.jsp/location
        /error-page

        error-page
         error-code500/error-code
                location/WEB-INF/view/jsp/errors.jsp/location
        /error-page

        error-page
                error-code404/error-code
                location//location
        /error-page

     error-page
         error-code403/error-code
         location/403.html/location
     /error-page

 I added this

        error-page
                exception-typejava.lang.Exception/exception-type
                location/WEB-INF/view/jsp/exception.jsp/location
        /error-page

 OK, what error page do you get if you cause the error without this entry?


 p

 --
 Jonathan Rosenberg
 Founder  Executive Director

 Tabby's Place, a Cat Sanctuary
 http://www.tabbysplace.org/


 Hi, Jonathan-

 From the Java Servlet Specification:

 The location element contains the location of the resource in the web
 application relative to the root of the web application. The value of the
 location must have a leading ‘/’.

 I specify locations as I would access them from the web. For example, and
 depending on how your JSPs are mapped, I would use:

 location/exception.jsp/location

 as the location sub-element for the java.lang.Exception error page. The
 leading /WEB-INF/view/jsp might be getting in the way.

 -Terence Bandoian



 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


Thanks to all for your ideas.

Re: Reinstall with 302 error

2012-01-28 Thread Bilal S

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)?
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 bc...@pitt.edu wrote:

 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.



 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.



 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).



 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.



 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.



 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=submitfile_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 - -

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

2012-01-28 Thread Ivan

So is the current behavior by design, or it is a defect ?

2012/1/28 Ivan xhh...@gmail.com

 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.caldar...@unisys.com

  From: Ivan [mailto:xhh...@gmail.com]
  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-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




 --
 Ivan




-- 
Ivan

Re: Reinstall with 302 error

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 bc...@pitt.edu wrote:
 
 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=submitfile_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

[OT] Re: TC7 very slow SessionIdGenerator SecureRandom initialization

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:dree...@gmail.com]
 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-devm=130182757504685w=2

 http://search.oracle.com/search/search?search_p_main_operator=allstart=1group=bugs.sun.comq=%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-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

-- 

[key:62590808]

signature.asc
Description: OpenPGP digital signature

Re: Connectors: Http11Protocol vs. Http11NioProtocol

2012-01-28 Thread André Warnier

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

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

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]



signature.asc
Description: OpenPGP digital signature

Re: Connectors: Http11Protocol vs. Http11NioProtocol


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-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

[OT] Re: Connectors: Http11Protocol vs. Http11NioProtocol