Java Mailing List Archive

http://www.junlu.com/

Home » users-digest.tomcat »

users Digest 21 Mar 2013 15:51:08 -0000 Issue 11307

users-digest-help

2013-03-21


Author LoginPost Reply

users Digest 21 Mar 2013 15:51:08 -0000 Issue 11307

Topics (messages 240603 through 240623)

Re: [OT] Sharing lots of little pieces of data across a cluster
 240603 by: Albert Kam
 240614 by: Christopher Schultz
 240615 by: Howard W. Smith, Jr.

Re: OCSP with TOMCAT 7
 240604 by: Amit A
 240606 by: André Warnier
 240613 by: Martin Gainty

Re: [tomcat] preventing to use it at startup
 240605 by: Stadelmann Josef
 240608 by: André Warnier
 240609 by: Mark Thomas
 240617 by: Christopher Schultz
 240619 by: Mark Thomas

Re: BIO acceptorThreadCount
 240607 by: Mark Thomas
 240616 by: Christopher Schultz
 240620 by: Mark Thomas

Re: [a bit, but not totally OT] Tomcat Behavior on Multiple HTTP requests from same browser
 240610 by: André Warnier
 240618 by: Christopher Schultz
 240621 by: André Warnier

Apache Tomcat 7.0.037 starting issue on Windows 2003 Server 64 bit machine
 240611 by: Geett Chanddra Singha
 240612 by: Konstantin Kolinko

Re: Adding Connectors
 240622 by: Christopher Schultz
 240623 by: Steffen Heil (Mailinglisten)

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_240603.eml (zipped)
I am not sure this might suit you, but if i am currently thinking of
http://redis.io/
Key and value storage (binary value is supported), expiry is supported,
support scaling horizontally, can be set to be non-persistent (only in
memory, which is fast)

For more complex data structures, and more ability in queries, i would
suggest http://www.mongodb.org/
They have json-like storage, expiry is also supported, scaling horizontally
with sharding, support replicas for availability, and although it's always
in persistent mode, the active workset would be in the mapped-memory for
fast access.



On Thu, Mar 21, 2013 at 7:39 AM, Christopher Schultz <
chris@(protected):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> All,
>
> I have an in-process "service" that stores valid nonces on a server
> for a particular set of client operations. The nonces are created
> once, then expire after a certain amount of time. They never change.
> I'd like to make this in-process service into an out-of-process
> service that can be accessed by any node in my cluster, basically
> acting like a communal hash map.
>
> Memcached is the perfect application for this kind of thing, right? It
> is fast and simple, plus supports key expiration out of the box.
>
> Doing a bit of reading (I've never actually used memcached before), it
> seems like memcached is better-suited as a /cache/ -- that is,
> something that sits between a slow data source and clients. They
> suggest that you /not/ configure "failover" but instead allow a dying
> node in your memcached cluster to simply die and consider the data
> lost: go back to the canonical data source and re-fetch the data. In
> my case, I have no (other) canonical data source: I just want to use
> memcached.
>
> (Note that if the whole service were to fall-over and I had to restart
> the nonce-storage cluster and start with a completely empty
> "database", it wouldn't be the end of the world. There would be a lot
> of grumbling, because everyone would have to request new nonces and
> re-start any transactions that were using them.)
>
> Also, the memcached servers don't really know about each other, right?
> So, it's not really a big, shared hashtable. Instead, it's like a
> bunch of separate hash tables and the client knows which server ought
> to have the data when it requests it based upon the key.
>
> Am I barking up the wrong tree by looking at memcached? Is there
> something else that would be better for me? It's a simple enough set
> of requirements that writing it myself could be done easily. Then
> again, it's a simple enough set of requirements that someone /must/
> have done this before me.
>
> Thanks,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJRSla3AAoJEBzwKT+lPKRYGpsP+wW0kKEjm5k0p2cFrRDF9KAr
> y5SWi3GWCPSNRbOJkR487CRfFN9cUCuyiq1+wuQrtbhG2osdeLUIb4dS7NOCTRh8
> dknyZvGQw9BrBZXvUeVQnMsLrD02YE6qgEp8hAdnLZBoKLb8EOA1FACs2qdWaBW6
> 8XLxI6nw5yT/y6glP35syq/MfgjFsXdn8+2Wlu5KQdc6YciUMrG/L7ifB4Huxz+S
> NFqVCsXJeVQU6MGpL1Bucn135WE3dHrZWJlnnP38iq2cATzo+0SM6Yq4ul2APjye
> EoN252a5WXddEhzMyjRKC8U89XE8ELF44WiP9NN3niEyyHh035+iK3dawhpN40qi
> XUw87TbnbL/4cAk8wu2d+gD3BHAFl9SrmkAcJ8lPKpn+ExSzFcgXwldc/TJah+yh
> M8FOGNwF4FfOeVCkAEMEltsk9YJev8IQNPSAYKtI0tzzWtckmq0ujHQpBWd/2knw
> YtSQALT6cjx0oyJnRTG02Jx1I6OsOQgVaHcarb8ejAAqkK3I0pge1tNroMU2QaHD
> gNY5wl33msB5WpHRYlsmg0y+6bshjrOrJkpPoYpxuVgGZj5zrPls5WhuFk1zgZ6Z
> e7j1BMMF/xVykNKS/bO1T6hqGsjCFSXCfT7WURbkkQyQ85Yiyvcmcfrt2tnVFX0x
> dtB4zpCWED0XLw1CbG88
> =eJjT
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>
>


--
Do not pursue the past. Do not lose yourself in the future.
The past no longer is. The future has not yet come.
Looking deeply at life as it is in the very here and now,
the practitioner dwells in stability and freedom.
(Thich Nhat Hanh)

Attachment: users_240614.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Albert,

On 3/20/13 9:22 PM, Albert Kam wrote:
> I am not sure this might suit you, but if i am currently thinking
> of http://redis.io/ Key and value storage (binary value is
> supported), expiry is supported, support scaling horizontally, can
> be set to be non-persistent (only in memory, which is fast)

Okay, I'll check that out.

> For more complex data structures, and more ability in queries, i
> would suggest http://www.mongodb.org/

Ooh! Web-scale!

> They have json-like storage, expiry is also supported, scaling
> horizontally with sharding, support replicas for availability, and
> although it's always in persistent mode, the active workset would
> be in the mapped-memory for fast access.

One of the major draws of Memecached is its near-zero configuration:
just launch it and you've got an instance. I want to avoid a
full-blown "database" if possible.

Thanks for the thoughts: I'll give them (both) a good look.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRSwL6AAoJEBzwKT+lPKRYabsP/issbYZC8p1vxb0Uq8AoXz4R
mAdCbnOwU17TKUG4B6LrFHGYX1/fjVPwyEjWpmCbwUB5K4+9XIjX0LgzuTEgQx1m
mCjMSReB0iQQ53sAv1feyuOGIQ4e1dTsY0vDnIBKnt7CwyiN/EyCg/mAqHc8Tump
KUetnNWrJfn23mVQUfZGplLinzbbaRtdx1+tv4np+srezUtH/wwEgfPJEgwVWtoK
2w8a/jtrAaNmDFdvkSJ1mPVHei2IVru+ITyU+pbSX3IogHCqg8mnpvENqF+NT079
sVuKPT1oMMFgE3XQDNKySgrNDso8P+E4SowpSURDogeW6VciGuupkVw8OYVqQ0N/
2UlMoOHVAINSmBAdwgjy0u/8J7bAptz2y70IoFlofwTGm1RVZ2XNQPSilY2kngQO
ao6S+jWzsvoTdMdJAvFsYYsMHdRVFnlSz9qnqrDANiNsMpHIMEnPG2bhONMAjKjM
JHWRkPahkSyK3OjIqil8mgJ88DgLhFtzR+60Vfrg2X8nOrJDkDe4gP/pjfQPzQcp
w3ttCSmz0H0/vsYcWvOsrby/iw3/EFmjpC34r8lEQ10N3t1weDQm9wMluRP7Nkjd
Qg9xkoGJsoiajKbBYIlfFJ7K85WHFEZS89y+4FM/uMgOz5xVrL9s58L5ugT/x5XP
yVM/v9ZiWOuzjwmEobDF
=nYDY
-----END PGP SIGNATURE-----


Attachment: users_240615.eml (zipped)
On Thu, Mar 21, 2013 at 8:54 AM, Christopher Schultz <
chris@(protected):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> > For more complex data structures, and more ability in queries, i
> > would suggest http://www.mongodb.org/
>
> Ooh! Web-scale!
>
> > They have json-like storage, expiry is also supported, scaling
> > horizontally with sharding, support replicas for availability, and
> > although it's always in persistent mode, the active workset would
> > be in the mapped-memory for fast access.
>
> One of the major draws of Memecached is its near-zero configuration:
> just launch it and you've got an instance. I want to avoid a
> full-blown "database" if possible.
>
>
+1 (on all the above)

Attachment: users_240604.eml (zipped)
Could not find anything achived on this topic
Search query: http://marc.info/?l=tomcat-user&w=2&r=1&s=tomcat+ocsp&q=t

Further pointers please?


On Wed, Mar 20, 2013 at 4:23 PM, André Warnier <aw@(protected):

> Amit A wrote:
>
>> I need to enable OCSP on my application which is running Tomcat 7.0.29.
>> Looked up the documentation but did not find quite much :
>> http://tomcat.apache.org/**tomcat-7.0-doc/ssl-howto.html<http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html>
>>
>> 1. Is OCSP with just tomcat actually possible? Do we need a external
>> module/software?
>> 2. Has anyone implemented/Configured OCSP with Tomcat? I am looking for
>> the
>> nitty gritties here.
>>
>>
>> Search the list archives. There was a question/response about this
> exact subject just a few days ago.
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<users-unsubscribe@(protected)>
> For additional commands, e-mail: users-help@(protected)
>
>

Attachment: users_240606.eml (zipped)
Amit A wrote:
> Could not find anything achived on this topic
> Search query: http://marc.info/?l=tomcat-user&w=2&r=1&s=tomcat+ocsp&q=t
>
> Further pointers please?

15/03/2013, subject "Standard or OCSP Native Lib?", Nick Williams ?

>
>
> On Wed, Mar 20, 2013 at 4:23 PM, André Warnier <aw@(protected):
>
>> Amit A wrote:
>>
>>> I need to enable OCSP on my application which is running Tomcat 7.0.29.
>>> Looked up the documentation but did not find quite much :
>>> http://tomcat.apache.org/**tomcat-7.0-doc/ssl-howto.html<http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html>
>>>
>>> 1. Is OCSP with just tomcat actually possible? Do we need a external
>>> module/software?
>>> 2. Has anyone implemented/Configured OCSP with Tomcat? I am looking for
>>> the
>>> nitty gritties here.
>>>
>>>
>>> Search the list archives. There was a question/response about this
>> exact subject just a few days ago.
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<users-unsubscribe@(protected)>
>> For additional commands, e-mail: users-help@(protected)
>>
>>
>



Attachment: users_240613.eml (zipped)
so you want Tomcat7 to act as an OCSP Responder?

download and install ocsp daemon ..this is not trivial as you will need to be able to communicate to a working LDAP server
http://www.openca.org/projects/ocspd/

configure your servlet to serve its requests to ocsp-daemon calls..
configure the servlet to serve the response with the results from the ocsp-daemon

Please explain why you want to FE the ocspd request instead of calling the daemon directly?

Martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.




> Date: Thu, 21 Mar 2013 10:08:08 +0100
> From: aw@(protected)
> To: users@(protected)
> Subject: Re: OCSP with TOMCAT 7
>
> Amit A wrote:
> > Could not find anything achived on this topic
> > Search query: http://marc.info/?l=tomcat-user&w=2&r=1&s=tomcat+ocsp&q=t
> >
> > Further pointers please?
>
> 15/03/2013, subject "Standard or OCSP Native Lib?", Nick Williams ?
>
> >
> >
> > On Wed, Mar 20, 2013 at 4:23 PM, André Warnier <aw@(protected):
> >
> >> Amit A wrote:
> >>
> >>> I need to enable OCSP on my application which is running Tomcat 7.0.29.
> >>> Looked up the documentation but did not find quite much :
> >>> http://tomcat.apache.org/**tomcat-7.0-doc/ssl-howto.html<http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html>
> >>>
> >>> 1. Is OCSP with just tomcat actually possible? Do we need a external
> >>> module/software?
> >>> 2. Has anyone implemented/Configured OCSP with Tomcat? I am looking for
> >>> the
> >>> nitty gritties here.
> >>>
> >>>
> >>> Search the list archives. There was a question/response about this
> >> exact subject just a few days ago.
> >>
> >>
> >> ------------------------------**------------------------------**---------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<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_240605.eml (zipped)
Thanks and your right Jeffery,
but our Server is OpenVMS and we don't have any Server side firewalls
installed. So I would need to check if there is a FW SW for OpenVMS.
Josef

-----Ursprüngliche Nachricht-----
Von: Harris, Jeffrey E. [mailto:Jeffrey.Harris@(protected)]
Gesendet: Mittwoch, 20. März 2013 17:26
An: Tomcat Users List
Betreff: RE: [tomcat] preventing to use it at startup



> -----Original Message-----
> From: Stadelmann Josef [mailto:josef.stadelmann@(protected)]
> Sent: Wednesday, March 20, 2013 12:15 PM
> To: Tomcat Users List
> Subject: AW: [tomcat] preventing to use it at startup
>
> Thank you Jeffrey
>
> BUT
> we are not FW owner, AND
> we are so tiny little smalls in the AXA world AND our holly FW
> godfather admin is keeping his fingers on the holly FW.
>
> But why can tomcat not close and open the port 8080 and keep it in a
> way inexistent for external access unless the server is really up!
> I am not a TCP socket expert, so I do not know what else we can do to
> prevent that a request from our users reaching the server too early.
>
> How is that normally I intend to GET a html page and get the return
> saying "Sorry but server maintenance work is in progress blab la bla"?
>
>
> Josef
>

Josef,

I am suggesting that you use the firewall on the local server, not the network ("holly") firewall.
If you have access to the server, you can configure a local firewall. Both Windows and Linux have built-in firewalls, and generally they are already active, but you may need to turn them on if they are disabled, and they will need to be configured to open and close port 8080.

Jeffrey Harris

This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.

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



Attachment: users_240608.eml (zipped)
Stadelmann Josef wrote:
> Hi
>
> Is there an easy way to manage, to prevent, that my AS Tomcat is serving
>
> request before it is fully up and running; while fully up means - it has
> deployed
> all web apps and web app axis2 (a servlet engine) is up and has deployed
> all its
> modules *.mar and web service archives *.aar before any requests for
> this web
> services are accepted.
>
Hi.
I believe that the basic answer to this question is no.
The only thing which knows when an application is ready to answer requests is .. that same
application.

It is not very clear to me what the "bindOnInit" Connector attribute means exactly in that
respect :

bindOnInit  

Controls when the socket used by the connector is bound. By default it is bound when the
connector is initiated and unbound when the connector is destroyed. If set to false, the
socket will be bound when the connector is started and unbound when it is stopped.

(It is probably my lack of knowledge of what precisely is meant by "the connector is
initiated" versus "the connector is started" here)

But even assuming that it delays the moment when the Connector binds to the port (meaning
that until then, the listening port is not open, and no clients can connect to it), the
Connector is shared between /all/ applications, so I think that it would be difficult for
the Connector "to know" when /all/ applications are really "ready". Different
applications may have different ideas of when they are really "ready to serve requests".

If this is really vital for you, I would look at a servlet filter wrapping your
application, and some means of communication between that filter and your application.
For example, as long as some "ready flag" is not set, the filter would redirect all
requests to some "sorry" page; once the flag is set, it would let the requests go through.
And the application would set this flag when it considers itself to be "ready".

Over the years on this list, there have been several questions also related to a
synchronisation between *different* applications, which is also difficult to do, because
different applications are supposed to be independent of eachother.
So may, writing this as a <Valve> (tomcat-specific) at the Host level would be more
generic and fill some other needs too.


Attachment: users_240609.eml (zipped)
On 21/03/2013 09:57, André Warnier wrote:
> Stadelmann Josef wrote:
>> Hi
>>
>> Is there an easy way to manage, to prevent, that my AS Tomcat is serving
>>
>> request before it is fully up and running; while fully up means - it has
>> deployed all web apps and web app axis2 (a servlet engine) is up and
>> has deployed
>> all its
>> modules *.mar and web service archives *.aar before any requests for
>> this web
>> services are accepted.
>>
> Hi.
> I believe that the basic answer to this question is no.
> The only thing which knows when an application is ready to answer
> requests is .. that same application.
>
> It is not very clear to me what the "bindOnInit" Connector attribute
> means exactly in that respect :
>
> bindOnInit  
>
> Controls when the socket used by the connector is bound. By default it
> is bound when the connector is initiated and unbound when the connector
> is destroyed. If set to false, the socket will be bound when the
> connector is started and unbound when it is stopped.
>
> (It is probably my lack of knowledge of what precisely is meant by "the
> connector is initiated" versus "the connector is started" here)
>
> But even assuming that it delays the moment when the Connector binds to
> the port (meaning that until then, the listening port is not open, and
> no clients can connect to it), the Connector is shared between /all/
> applications, so I think that it would be difficult for the Connector
> "to know" when /all/ applications are really "ready". Different
> applications may have different ideas of when they are really "ready to
> serve requests".

The connector is not started until all web applications have been
started. That means that:
- all loadOnStartup servlets have been loaded
- all ServletContextListeners have completed
- etc.

It also means that Tomcat has finished its internal startup for the
Contexts, Host(s) and Engine.

There are no hooks (apart from receiving a request) for a web
application to trigger any further initialisation so it must be ready to
process requests at this point.

Mark



Attachment: users_240617.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 3/21/13 6:17 AM, Mark Thomas wrote:
> The connector is not started until all web applications have been
> started. That means that: - all loadOnStartup servlets have been
> loaded - all ServletContextListeners have completed - etc.
>
> It also means that Tomcat has finished its internal startup for
> the Contexts, Host(s) and Engine.
>
> There are no hooks (apart from receiving a request) for a web
> application to trigger any further initialisation so it must be
> ready to process requests at this point.

When a webapp is reloaded, the connection will remain running with no
interruption, right? Requests to that webapp will stall until the
webapp is back up again?

IIRC, it used to be that during a webapp reload, you might get weird
responses either from Tomcat or the ROOT webapp (it might have been
because I was running without a ROOT webapp, which I have since fixed).

What about the case of re-deployment? Does it behave just like a reload?

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRSwXTAAoJEBzwKT+lPKRYxZ0P/1lMCCYW6+TrJTL6PdWT7Ge8
D3MVmcP+5xpmglaMJXw1ssf7nOmBDlalzRGHT1MZywPVcPAzZWrVAjdRqGrQqU0p
AXpYxe9LVFm7+1wa1zvmX+FgXX59AHpLtlX+xHxhF38VtYD2H4u6VxtqEj4dnUGS
mpSH7q7on8VkVsSZqA8zEKO5Qwkrt9WDXrl8C2CVWB4xLv/5pWEtMZQ00Fbo8Yw5
4bpvMGqH9rEwVFcDqH/OmFAynm3qUS6R6YcDcHVlyZbIasKKfSDCDv/wN8ZROsFt
Szv6ee0wvvsEu6CN9R9nongAPvqXRphr4CD1inffXoWQcrMIZ1Vp5ooCG6zY30GM
CGjHmXCVb9Tr8Cn+md7nxd1XOZc1QRxm0skPkxankL92wUw4unAvZ4mZ4L9Xie3E
RQUuYHw1MheaoC3qPHi0WOMlkI3ijppX9A5rwAo7wpqM4TSqOkA35E3OzTOSwBsa
RABgNRhj8CAp+Fa5or6vwa1bf24rRa8p5EgR30/pFHF4kUrkygEc0fC1Xg71igTj
NoS+Ixl48tVIw/G1GLrSbv3WXYfwIwE223DSjg7ciRwGohzvgRoTejr3Fz9s/gsa
ul08kisYp722JirBqVHL7GnQ3z7XId+EUD1tMmFtCqEEPJtV8Oxm+YRDbmpj3cKb
IV8GwpTeA1FGEEUYkWcx
=TWBd
-----END PGP SIGNATURE-----


Attachment: users_240619.eml (zipped)
On 21/03/2013 13:06, Christopher Schultz wrote:
> Mark,
>
> On 3/21/13 6:17 AM, Mark Thomas wrote:
>> The connector is not started until all web applications have been
>> started. That means that: - all loadOnStartup servlets have
>> been loaded - all ServletContextListeners have completed - etc.
>
>> It also means that Tomcat has finished its internal startup for
>> the Contexts, Host(s) and Engine.
>
>> There are no hooks (apart from receiving a request) for a web
>> application to trigger any further initialisation so it must be
>> ready to process requests at this point.
>
> When a webapp is reloaded, the connection will remain running with
> no interruption, right? Requests to that webapp will stall until
> the webapp is back up again?

Yes. They will he held by Tomcat until the web app is back up.

> IIRC, it used to be that during a webapp reload, you might get
> weird responses either from Tomcat or the ROOT webapp (it might
> have been because I was running without a ROOT webapp, which I have
> since fixed).

That was mostly likely one of the bugs in this area that got fixed.

> What about the case of re-deployment? Does it behave just like a
> reload?

No. You'll get 404s.

Mark


Attachment: users_240607.eml (zipped)
On 21/03/2013 00:13, igaz wrote:
> I was curious as to people's actual experience with setting a Connector's
> acceptorThreadCount while using the BIO http connection (the default)
>
> Frankly, I was unaware that java.net.ServerSockets were multi-thread safe
> (although interestingly the javadoc explicitly states that
> ServerSocketChannels are)
>
> Has anyone seen throughput increase with larger # of acceptorThreads? Did
> you set it == to # of hardware threads?

It makes a marginal improvement if you increase it to 2 (assuming you
have two+ cores). There is no improvement beyond 2. There is an
underlying sync block for accepting new connections.

Mark



Attachment: users_240616.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 3/21/13 5:49 AM, Mark Thomas wrote:
> On 21/03/2013 00:13, igaz wrote:
>> I was curious as to people's actual experience with setting a
>> Connector's acceptorThreadCount while using the BIO http
>> connection (the default)
>>
>> Frankly, I was unaware that java.net.ServerSockets were
>> multi-thread safe (although interestingly the javadoc explicitly
>> states that ServerSocketChannels are)
>>
>> Has anyone seen throughput increase with larger # of
>> acceptorThreads? Did you set it == to # of hardware threads?
>
> It makes a marginal improvement if you increase it to 2 (assuming
> you have two+ cores). There is no improvement beyond 2. There is
> an underlying sync block for accepting new connections.

I've often wondered about that note in the documentation about the
acceptorThreadCount. When you say "there is an underlying sync block",
is that the explanation for why many threads will not improve the
situation, or just additional information?

If there is a sync block, why will two threads improve things --
because the small amount of time dispatching a connection is still
large compared to the time required to acquire the lock?

These days, almost everyone has 2+ cores, even in development
environments. Would it make sense to change Tomcat's default
acceptorThreadCount to 2 if it is likely to improve performance, even
if only slightly? We could even detect the number of processors before
doing such a thing...

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRSwUpAAoJEBzwKT+lPKRY9eAP/iegkG5tkQscQG5wc+2kUnwO
UyN5y3dKPFJyjfq2QX/3kVi18B3N1K7/HqYDq3b985TPmem+/VeQgzw8FIBZXy7o
qDe2M5SOyqnnCzgNcfQZxhQnbgGYsk8eweUCBBJFQyIGIEji7dGs9emUizkr74mn
9z6YP1aaUboG7yUPX0Y/W53Hxl5llopBuBQGSotJhFk43ABY9cxAeL+JLmMYiBWO
qaGwg8bT3Ixrkd9R9s5IZwCXDu2kA7MHKVvWoVAxVuauTR/2emXc/48BP7GV5o13
YH70ikgLpg/AZLX+c5MbYeTtV3Q4RhUPTOSqZZRs6w8BLfU1sfwjVQSPGNPtCUCa
tE2aLAZGgCvnsDXFcp8mt+FjYZ5Zgvk2Ln3cXyTmBfaD6F0BXN3fDWlSzM2JrCXt
73WG2LtvyDKX+WhOcpBhT73rQj30rliDTEVuG1lF5BLur975bksIO9bQ2BECKLTX
uS+2Yz8XTF/jk6wz23NTTl7DRPvHEz++fpBQJp04aYMTYObld4J6nz+PGlKAshqt
lJhLTnawb2juAhuMYDz002HrQZQUp4Fsy1VDEXbU+xtfj/Rr3i/bWSlW8VXWxnxc
dIItRfbSTYALOrLLUwQhOgvzeIbUQLT0KdnjFA22qGJs371GzOrHhGoVRAXiFA/X
xCTPcshUF4TZEyxTUYtT
=/XHi
-----END PGP SIGNATURE-----


Attachment: users_240620.eml (zipped)
On 21/03/2013 13:03, Christopher Schultz wrote:
> Mark,
>
> On 3/21/13 5:49 AM, Mark Thomas wrote:
>> On 21/03/2013 00:13, igaz wrote:
>>> I was curious as to people's actual experience with setting a
>>> Connector's acceptorThreadCount while using the BIO http
>>> connection (the default)
>>>
>>> Frankly, I was unaware that java.net.ServerSockets were
>>> multi-thread safe (although interestingly the javadoc
>>> explicitly states that ServerSocketChannels are)
>>>
>>> Has anyone seen throughput increase with larger # of
>>> acceptorThreads? Did you set it == to # of hardware threads?
>
>> It makes a marginal improvement if you increase it to 2
>> (assuming you have two+ cores). There is no improvement beyond 2.
>> There is an underlying sync block for accepting new connections.
>
> I've often wondered about that note in the documentation about the
> acceptorThreadCount. When you say "there is an underlying sync
> block", is that the explanation for why many threads will not
> improve the situation, or just additional information?

Explanation.

> If there is a sync block, why will two threads improve things --
> because the small amount of time dispatching a connection is still
> large compared to the time required to acquire the lock?

Yes. The acceptor thread spends some time dispatching the request that
a second thread can spend inside the lock getting the next connection.

> These days, almost everyone has 2+ cores, even in development
> environments. Would it make sense to change Tomcat's default
> acceptorThreadCount to 2 if it is likely to improve performance,
> even if only slightly? We could even detect the number of
> processors before doing such a thing...

I thought Filip had done that for at least one of the connectors. If
it doesn't apply to all, it should.

Mark


Attachment: users_240610.eml (zipped)
Christopher,

Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> André,
>
> On 3/20/13 2:25 PM, André Warnier wrote:
>> Saurabh Agrawal wrote:
>>> All our assets are served from L3 CDN. So the asset requests
>>> never come to the application server.
>> That, I do not understand. I do not understand what you mean by
>> "assets" here, and I do not understand "L3 CDN". So I cannot tell
>> of this is relevant or not to the problem.
>
> CDN = Content Delivery Network. I'm not sure what "L3" (probably
> "Level 3", a data center operations company) is, but a CDN is
> basically a whole bunch of copies of your files geographically
> distributed such that requesting a file always gets the bits that are
> closest to you. Kind of a cool thing. ;)
>

Thank your for the above Rosetta Stone. This computer business os so full of acronyms of
all kinds - some of them with multiple interpretations - that it is sometimes difficult to
grasp the meaning. And I really don't feel like having to use Wikipedia every 3 words of
a post on the list. Not when "static content is delivered by the Apache front-end" would
have done it.

> The bottom line is that Saurabh expects only dynamic requests to come
> to Tomcat, so keepalives should be much less useful than if Tomcat
> were to be serving everything. Imagine httpd out front serving all
> static content and forwarding dynamic stuff to Tomcat via AJP --
> that's almost exactly what's going on here, except that the static
> stuff is being served very efficiently from a network-topology
> perspective.
>
> Since AJP is in use, keepalive is almost entirely a red herring as
> typical AJP connections are permanently-connected to the web server.
>

Well, I would say so indeed forthe case of a html page wit embedded images e.g.
Butit may not be so in the "benchmark" case that Saurabh explained, with each of the 10000
clients making multiple requests to non-static content, presumably served by Tomcat.
A human user may have delays, that his testcase might not have.

>> So, by default, the keepAliveTimeout [for AJP] is set to
>> "infinite".
>>
>> [snip]
>>
>> And if the client keeps the connection open, but does not send any
>> additional request on that connection, the Thread will wait
>> theoretically forever (because that is what the documentation says
>> about the default value of these parameters).
>
> No, the defaults are different for non-AJP connections. Tomcat's
> default default is 60 seconds but the stock server.xml configures it
> to 20 seconds.

Right. But my explanation was meant as an example only, to point out the interlinked
effects of the various attributes and timeouts.
And 20 seconds is still an incredibly long time, in the context of 10000 "simultaneous"
clients sending multiple requests each.

>
>> Now your case is a bit different, because - you are not using the
>> HTTP BIO connector (you use AJP)
>
> I think you've gotten yourself confused, here, unfortunately. You can
> use AJP with BIO, NIO, or APR (maybe you mixed-up AJP and APR between
> your eyes and your brain... the two are honestly too close to each
> other and it is very easy to do that).

Yes, I was confused and thank you for making me see the light. I though that the AJP
Connector was a beast all of it's own, and did not "use" these different underlying
layers. It is clear fom the documentation that it does though, I don't know how I could
have overlooked that for so long.

>
> He is in fact using the BIO connector because he has specified
> protocol="org.apache.coyote.ajp.AjpProtocol".
>
>> - in front of your Tomcat, is an Apache httpd server. This server
>> has its own keep-alive settings which apply to the connection of
>> the client with Apache httpd. And these keep-alive settings are a
>> bit different from the Tomcat ones (for example, there is a
>> keep-alive timeout, but also a MaxKeepAliveRequests)
>
> +1
>
>> - between Apache httpd and Tomcat, there is the mod_jk module in
>> Apache, and that module uses its own timeouts (as set in
>> workers.properties), and in addition it uses itself a pool of
>> connections to Tomcat, and this pool of connections has its own
>> rules for keeping alive a connection between Apache and Tomcat.
>>
>> But the basic principles above apply, and may explain why you are
>> seeing what appears to be one Thread dedicated to one client,
>> forever.
>
> I think there might be a problem with the instrumentation, or just
> coincidences at a fairly implausible level. The trust of the matter is
> that Tomcat does not allocate a thread permanently to a remote client
> until ... whenever the client "disconnects" (whatever that means, as
> HTTP is a connection-less protocol).

(See the nitpick (*) below)

Possible, but see above again with the httpd/tomcat connections managed by the mod_jk
module. It does have and manage its own pool of connections, with each connection
potentially "staying alive" for a time much longer than any individual client request.
I do not deny that.
But what I am not so sure of (and maybe Rainer could comment here) is this scenario :
- a client, via httpd+mod_jk, sends a single request to tomcat on a keep-alive connection,
and receives a response. Now the client does not send another request anymore on the same
connection, but keeps it open "just in case".
Now say that at the client/httpd level, the keep-alive timeout is set to 30 seconds; and
say that on the Tomcat AJP connector, the keep-alive timeout is set for 20 seconds.
What really happens ?
After this first request, Apache httpd would have to keep the client/httpd connection
alive for 30 seconds, right ? At the Apache-httpd level, that means that this "Apache
child" process keeps its connection to the client open, and sits there waiting for another
request. Mod_jk is not a separate animal; it is an Apache module, so it is code
"embedded" in this one Apache-httpd child process.
So what does mod_jk really do ? he needed one connection to Tomcat, to send the first
request and get the response, so he got it from the pool of connections.
mod_jk is aware that the client/httpd connection is keepalive, and it does not have any
way to know that this client is not going to send another request to Tomcat. So what does
mod_jk really do ?
Does it relinquish the one connection that he had to Tomcat back to the pool immediately
after the first response has been served ? or does it keep its handle on that pool
connection until the client/httpd timeout has expired ?
And assuming for a moment that it keeps this handle to himself for a while, what does that
mean at the Tomcat level ? is a Tomcat Thread also waiting on that same httpd/tomcat
connection (at least for 20 seconds) ? or do Tomcat Threads *always* go back to the pool
after serving one request ? or does it depend, and on what ?

There is also kind of a weird question here : what is really the purpose of the
keepAliveTimeout attribute on the Tomcat AJP Connector ? I mean, connections to that
Connector always come from some front-end module (be it mod_jk, mod_proxy_ajp or the
isapi_redirector). (It is very unlikely that they would come from some independent
AJP-capable client).
Why would the AJP Connector need its own keepAliveTimeout attribute, if these front-end
modules are themselves managing their connections to Tomcat, in the way that they deem
appropriate ?
These front-end modules could pass to Tomcat the timeout that /they/ want, when they open
their individual pool connections to Tomcat, right?
Isn't that Connector keepAliveTimeout then more confusing than really useful ?
(And I guess that the same could be said for the connectionTimeout).

Come to think of it, that is probably why, in the case of the AJP Connector, the defaults
are "infinite". And maybe the attributes are left accessible for the rare edge cases where
they could prove useful.
If so, then I guess that a small note in the documentation would be useful.


(*) nitpick about HTTP being connection-less : that may be true in the sense that each
request+response is supposedly independent from any other request+response. But HTTP 1.1
explicitly introduces "persistent" TCP connections. And Microsoft has its own take on
this, as for instance for Windows Integrated Authentication purposes, it is the
*connection* which is authenticated, and each time the connection changes, the client has
to re-authenticate. So the practice is a bit less connection-less than the theory.


Attachment: users_240618.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

André,

On 3/21/13 7:15 AM, André Warnier wrote:
> Christopher Schultz wrote:
>>
>> I think there might be a problem with the instrumentation, or
>> just coincidences at a fairly implausible level. The trust of the
>> matter is that Tomcat does not allocate a thread permanently to a
>> remote client until ... whenever the client "disconnects"
>> (whatever that means, as HTTP is a connection-less protocol).
>
> (See the nitpick (*) below)
>
> Possible, but see above again with the httpd/tomcat connections
> managed by the mod_jk module. It does have and manage its own pool
> of connections, with each connection potentially "staying alive"
> for a time much longer than any individual client request. I do not
> deny that.

Right, but the AJP connections are managed in a connection pool. I
haven't really checked-into this, but I suspect that two requests
coming from the same keepalive connection have no guarantee of being
sent across the same AJP connection to Tomcat, and thus no guarantee
that they will be served by the same JVM thread.

> mod_jk is aware that the client/httpd connection is keepalive, and
> it does not have any way to know that this client is not going to
> send another request to Tomcat. So what does mod_jk really do ?
> Does it relinquish the one connection that he had to Tomcat back to
> the pool immediately after the first response has been served ? or
> does it keep its handle on that pool connection until the
> client/httpd timeout has expired ?

It would be a mistake for mod_jk to retain control of the AJP
connection for that keepalive request -- there's no guarantee that the
/next/ request across that connection would even be routed through
mod_jk: it might be for some other resource that another module handles.

> There is also kind of a weird question here : what is really the
> purpose of the keepAliveTimeout attribute on the Tomcat AJP
> Connector ?

+1

> (*) nitpick about HTTP being connection-less : that may be true in
> the sense that each request+response is supposedly independent from
> any other request+response. But HTTP 1.1 explicitly introduces
> "persistent" TCP connections.

Yes, and HTTP sessions are standard fare these days, too. But the fact
is that HTTP itself is connection-less. We as engineers can make it
feel like it's not and do stupid things like put JDBC connections into
HttpSession objects and try to tie everything together to make the
user feel like they have a permanent connection. We can even hold-open
HTTP connections for long periods of time, but that's really abuse of
the protocol IMO. You can send bowling balls via carrier pigeon, but
there are better ways to send bowling balls.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRSwfNAAoJEBzwKT+lPKRYAMgQAKyONnliLXad6HDwO9raxN+d
evcEl8zAeYr6vbevZJ/KJK/FALoFVOmHdMDj+twGEWM+zrIOkHel2y9LHKzxR+St
6Fz1466yDeHM45D/PBcyMow2WaOSR9a6Ewj8uDprJLuVjT20qRlaiw0pQjvfB5M2
rPfX0rEP6NPMQNaTTdaTiq56LP4j/kNMiIhNZyZrq3Gu+9hP/LGEZgKW4j9PDPRF
wvNUnWrHwhl4cUJwtRF1CuyynmJmnsrglQWpLgj1cYvBnzHp/19I3CKUevut5JUj
NtcCmZ+u/is9zsJbWn6g1yRpyVFNForyV2XF2UFMDm/4UO+Ofyq1lVsGtvkMu3b2
2PQ7vMPqMM34JBySI3ZWVMFxD3GZUMm+Bqc4H5iKIzcGxRg0MgQn5z6DHniuIOmw
lUxsjiwHiJ8xF/W3cdN1cxzPPzG92MOp4FWpsnMF+XcAN8ctGr5MuRJzDJKfct1o
VcQojNqhmDyBHlJd3188aAz94KUXIGyXkmsLNdvnYhSZLZWxjFwBNxYm/4RzmHeA
Dm/Heoe+qpxsk868YGKvJcIAk/1Rdxje8ZEJv44YRNXyCqfDkq0t9HUCduzyNBJF
4H/RVCSSS6OEXvdXUMywS2JJElcss560fSZ1ZF45YSW6NiLMIyl5PjFR1mb0Kfsf
YYwN2L9egDE8ZDibeON2
=Bxsy
-----END PGP SIGNATURE-----


Attachment: users_240621.eml (zipped)
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> André,
>
> On 3/21/13 7:15 AM, André Warnier wrote:
>> Christopher Schultz wrote:
>>> I think there might be a problem with the instrumentation, or
>>> just coincidences at a fairly implausible level. The trust of the
>>> matter is that Tomcat does not allocate a thread permanently to a
>>> remote client until ... whenever the client "disconnects"
>>> (whatever that means, as HTTP is a connection-less protocol).
>> (See the nitpick (*) below)
>>
>> Possible, but see above again with the httpd/tomcat connections
>> managed by the mod_jk module. It does have and manage its own pool
>> of connections, with each connection potentially "staying alive"
>> for a time much longer than any individual client request. I do not
>> deny that.
>
> Right, but the AJP connections are managed in a connection pool. I
> haven't really checked-into this, but I suspect that two requests
> coming from the same keepalive connection have no guarantee of being
> sent across the same AJP connection to Tomcat, and thus no guarantee
> that they will be served by the same JVM thread.
>
>> mod_jk is aware that the client/httpd connection is keepalive, and
>> it does not have any way to know that this client is not going to
>> send another request to Tomcat. So what does mod_jk really do ?
>> Does it relinquish the one connection that he had to Tomcat back to
>> the pool immediately after the first response has been served ? or
>> does it keep its handle on that pool connection until the
>> client/httpd timeout has expired ?
>
> It would be a mistake for mod_jk to retain control of the AJP
> connection for that keepalive request -- there's no guarantee that the
> /next/ request across that connection would even be routed through
> mod_jk: it might be for some other resource that another module handles.

On the other hand, if there were 10 successive requests for Tomcat from the same client on
the same connection, then it might be argued that it would be counterproductive to return
the connection to the pool each time, just to go obtain another one right after, and this
10 times in a row.

May be there should be an "adaptative" or "predictive" algorithm here : if this client in
the recent past has always sent several requests in short succession, then maybe I'll keep
this connection for now, just in case he does it again.
I can already hear Rainer saying "patches are always welcome".
;-)

But the real point is : does mod_jk keep the connection, or does it return it to the pool
at the end of each response ? Barring Rainer reading this, I guess that only looking at
the code would tell.

Note that Apache httpd already maintains the client/httpd connection, and keeps a count of
how many requests have been received over this connection. It has to, for
MaxKeepAliveRequests. So it would not be too much of a complication for mod_jk to keep
its own count, of how many requests forwarded to Tomcat have been received over this same
connection. That would already be a good predictor of whether the same is likely in the
future.
a = time for which this client connection has been alive
b = number of requests forwarded to tomcat over this connection
c = a / b = average time between 2 requests forwarded to tomcat
if c is lower than the overhead for obtaining and returning a connection from the pool,
then keep the connection.
It would be self-adaptative, because if the client slows down its request rate, then c
would become larger, and the connection would be returned to the pool; and vice-versa.

>
>> There is also kind of a weird question here : what is really the
>> purpose of the keepAliveTimeout attribute on the Tomcat AJP
>> Connector ?
>
> +1
>
>> (*) nitpick about HTTP being connection-less : that may be true in
>> the sense that each request+response is supposedly independent from
>> any other request+response. But HTTP 1.1 explicitly introduces
>> "persistent" TCP connections.
>
> Yes, and HTTP sessions are standard fare these days, too. But the fact
> is that HTTP itself is connection-less. We as engineers can make it
> feel like it's not and do stupid things like put JDBC connections into
> HttpSession objects and try to tie everything together to make the
> user feel like they have a permanent connection. We can even hold-open
> HTTP connections for long periods of time, but that's really abuse of
> the protocol IMO. You can send bowling balls via carrier pigeon, but
> there are better ways to send bowling balls.

You would need a fairly large, and well-disciplined team of pigeons to do that though. I
don't think that this was a good metaphor, You should have chosen a bigger bird and/or a
smaller load. Eagles and tennis balls maybe ?
I should also probably remind you of RFC 1149 :
http://en.wikipedia.org/wiki/IP_over_Avian_Carriers


Attachment: users_240611.eml (zipped)
Hi,

I am trying to register and start Apache Tomcat 7.0.37 service on my
Windows 2003 Server 64 bit machine.

I am able to register Tomcat as a service using the service.bat file, but
when I try to start the service it gives the following error:

Could not start the Apache Tomcat tomcat7 service on Local Computer.
Error 1053: The service did not respond to the start or control request in
a timely fashion.

There is no error in Catalina Logs or any other log.

I follow the same process on a Windows 2003 Server 32 bit machine and a
Windows 2008 Server 32/64 bit machine. I am able to register
as well as start the service.

Environment:
            Apache Tomcat version 7.0.037
            JRE Version : 7.0.x
            OS: Windows 2003 Server 64 bit

Please help !
--
Thanks & Regards
Geett Chanddra Singha

Attachment: users_240612.eml (zipped)
2013/3/21 Geett Chanddra Singha <geetcs@(protected)>:
> Hi,
>
> I am trying to register and start Apache Tomcat 7.0.37 service on my
> Windows 2003 Server 64 bit machine.
>
> I am able to register Tomcat as a service using the service.bat file, but
> when I try to start the service it gives the following error:
>
> Could not start the Apache Tomcat tomcat7 service on Local Computer.
> Error 1053: The service did not respond to the start or control request in
> a timely fashion.


http://issues.apache.org/bugzilla/show_bug.cgi?id=54609


Attachment: users_240622.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Steffen,

I think this should be discussed on the users' list. I'm cross-posting
this message one time for that purpose. See below.

On 3/21/13 9:59 AM, Steffen Heil (Mailinglisten) wrote:
> I have a servlet that creates a new Connector and adds it to the
> Service it is running in. However it does this during startup of
> the Servlet.
>
> Obviously the connectors specified in the server.xml are added and
> NOT started. So tomcat starts its connectors as last thing after
> loading other components (including servlets).
>
> Therefor I get: INFO: The start() method was called on component
> [Connector[org.apache.coyote.http11.Http11NioProtocol-1001]] after
> start() had already been called. The second call will be ignored.
>
> Now, that would not be a problem for me, but I would like to add my
> connectors without starting them, so that at the end of startup
> sequence tomcat would start them as it does for all other
> connectors defined in server.xml.
>
> But I cannot. The following code shows the issue.
>
>
> package org.apache.catalina.core;
>
> public class StandardService extends LifecycleMBeanBase implements
> Service {
>
> public void addConnector(Connector connector) { ... if
> (getState().isAvailable()) { try { connector.start(); } catch
> (LifecycleException e) {
> log.error(sm.getString("standardService.connector.startFailed",connector),
> e); } } ... }
>
> }
>
>
> During servlet initialization getState().isAvailable() returns
> true, therefore the connector is started right away. Also, during
> start, if anything is accessed before the tomcat startup sequence
> completes, I get the following:
>
> Mar 21, 2013 1:36:34 PM org.apache.tomcat.util.net.NioEndpoint
> processSocket SEVERE: Error allocating socket processor
> java.lang.IllegalStateException: StandardThreadPool not started. at
> org.apache.catalina.core.StandardThreadExecutor.execute (StandardThreadExecutor.java:173)
>
>
at
org.apache.tomcat.util.net.NioEndpoint.processSocket (NioEndpoint.java:728)
> at
> org.apache.tomcat.util.net.NioEndpoint$Poller.processKey(NioEndpoint.java:1257)
>
>
at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1193)
> at java.lang.Thread.run (Thread.java:662)
>
>
> This is probably, because my connector is already started, while
> the Executor is not.
>
>
> Now, my two questions:
>
>
> a) Can I assume that those error messages do no harm?
>
> b) Isn't this a bug, that tomcat starts connectors while it regards
> all self-created connectors as not started?

What happens if you set bindOnInit=false in server.xml? That may only
affect those connectors defined there, but it may also put Tomcat into
a state where none of the Connectors are started until after webapp
initialization.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRSx1PAAoJEBzwKT+lPKRYDvcP/2+PTj7cA4ebJ2wcYV0CzLI8
y6qc+aDvls6BJf84lzzOtbZrGEiWvbGwp/dtNmHBmRJkOShlF790qqdKfhglhVCx
HckjEi0bpQLLv9IXB3y/5+byDITM43SAtgI2otUhaKy/vonE/TuHbE91pQZIZV4B
jHWpYUIhDXO6fzwfF69/mjEny6ekg1QtGfDTYVqG8Qle4HpXCEZFpSMAo8W97n2n
s6AMD/lbf2NRXbyExeV9vLcLd8XKXcxm4hUrOxiDVeEXk3OFUcoLR3+yLYVD4gfV
C7hUvmWdhiWPVjnAaTqY+JYHdgSTXfDdLg0dswtHtzKKRVxky0aR3ydDiZ3PqHR+
lGDZFJLfFGN6KXhYUMUhgnV4R0Mr6084zwCs5Af4LTP6yaeaeEtP7fQHFbQbZezr
gpA0+gaw3LWTJJWZw/hb4VHRt23XB+0N07xgHAL0g5FpPxPk0l1LxOzGPEtEW1vo
M35xTjA6eZQmYa9NGTW4gWQakSdjq+m341+OrFZmjmU4QMAPakcqfnzAS/IxA3TR
CaL2nw9b4kejDYBIxdI++CpOnTBnB4xTd+nnbD6XqMt0UUsm9kacNy4LkzJnwht/
hLZsmUpWBDCID2b3A8nB80ODDcnCxcvl7+0I+39IR5pWdWzArOTH1f32L9bZUP0j
KVPBk5kgar7W6/txeKsz
=sfnh
-----END PGP SIGNATURE-----


Attachment: users_240623.eml (zipped)
Hi


> I think this should be discussed on the users' list. I'm cross-posting this
> message one time for that purpose. See below.

Sorry, as I assumed that in a state where tomcat does not start connectors defined in server.xml it should also not start other connectors, I regarded this as a bug. That's why I sent it to the developers' list...


> What happens if you set bindOnInit=false in server.xml? That may only affect
> those connectors defined there, but it may also put Tomcat into a state
> where none of the Connectors are started until after webapp initialization.

By documentation it only conrols, wheather it is bound on init or start, not when it is started...
Anyway I would have tried your suggestion, but:

From the documentation I see on a "bindOnInit" for connectors.
However I don't have any connectors in my tomcat for usual deploys. (I did include one for debugging only.)


Regards,
Steffen


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