I've just installed Tomcat (7.0.67) on an old CentOS 5 box. It can't be reached from outside the box.

[James H. H. Lampert]

This is weird. I've never seen this before.

Then again, I don't think I've installed Tomcat on Linux from a tarball 
before: the previous CentOS installation was, if I remember right, via 
Yum, and the one Debian installation I've done was via apt-get.


But I can apparently no longer reach the Yum repository from our CentOS 
5 boxes, so I went with the tarball.


It launches. The port opens. It shows up in a netstat. And I can reach 
it at either 127.0.0.1:8080 or port 8080 at the box's own IP address.


From the box it's running on.

But if I try to reach it from other boxes on the same LAN, I get 
"Firefox can't establish a connection" whether I use the box's name 
(from boxes that have it in their host table), or its IP address.


I can ping the box. And I can reach Samba shares on it. And I can ssh to it.

The only firewall on the Lan is a TP-Link N750, and if it has any 
settings in place to block traffic within the LAN, I can't find them.


I've got three different Tomcat 7 servers all running on the LAN, and 
can reach them easily.


--
JHHL

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

Re: [OT] Session timeout despite user activity - websockets on Tomcat 8.5.16

[Guang Chao]

On Thu, Aug 10, 2017 at 12:46 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Mark,
>
> On 8/9/17 11:35 AM, Mark Thomas wrote:
> > On 09/08/17 16:09, David Wall wrote:
> >> We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and
> >> Atmosphere Websockets.
> >>
> >> We have had reports of sessions logging out while users are
> >> active with our Vaadin-based application.  This has been
> >> frustrating as we can't seem to track down why Tomcat's session
> >> is not being updated, but figure it's something to do with the
> >> websockets/push not updating Tomcat reliably.
> >>
> >> Our app shows a "last sent to server" timestamp that seems to
> >> keep current with user activity, updating as the user clicks on
> >> buttons, checkboxes, etc.
> >>
> >> We also have a "list of active sessions" screen that shows all
> >> active sessions including the HttpSession.getCreationTime() and
> >> HttpSession.getLastAccessedTime().  We see it appears as if the
> >> last accessed time stops being updated when using simple forms
> >> that perhaps update via websockets rather than HTTP requests.
> >> Our "last sent to server" timestamp shows each of these clicks
> >> updating it, but the HttpSession.getLastAccessedTime() is not
> >> updating.
> >>
> >> Is there something about push/websockets or anything else that
> >> would cause the HttpSession access time not to update?  I don't
> >> think we have a way to update it ourselves as I believe it's
> >> managed by Tomcat itself, but as Tomcat is handling the websocket
> >> requests, it's unclear why they are not tied to the HttpSession.
> >>
> >> Anybody have any ideas?  Thanks as we have a lot of frustrated
> >> users who would love for us to find out what's going astray.
> >
> > What you are seeing is expected behaviour. This was discussed in
> > the WebSocket EG. The short version is: - WebSocket requests don't
> > update the session's last accessed time - you need an HTTP request
> > from the browser to update the session's last accessed time (and
> > update the expiry time of the browser's session cookie) - so the
> > application has to do periodic HTTP requests.
> >
> > You can reduce the frequency of these requests by extending the
> > session timeout (remembering you need an HTTP request after this to
> > update the browser's cookie). You then need to be careful to reduce
> > the timeout again once WebSocket comms end.
>
> Websocket ignoramus, here. Is there a way for (websocket) application
> code on the server side to trigger a "touch" of the HttpSession that
> is linked with the connection? Or is the problem that the websocket
> connection and the HTTP connection are essentially independent?
>
>
Maybe just have a javascript with settimeout to poll heartbeat via http
request.


> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmLPEUACgkQHPApP6U8
> pFjVpRAAhIk//uWfkihpjwqp75MwDqe4mlAN3zbdvLoa4EU0QJyA8fZRnIFuO7Gg
> ksQYycpuGniEMPQH+l4Mb3T5/KogTkY3DZrBRh7vN+8oA3ELayuqTxDAdNjjsnmg
> uKWeYv3obL8pZQuSb5hVFXx4Dfe6pAXWk7CwuHls5Cs97lRqvN9C5lQM1QPArPpt
> nqNnDUm7HHmrSZVo82bdJxgXfpRXnoIg5qie3wGURHzdQK4JZGpZY7jJDAmM/HTW
> QNHg2saIFR1ce5YdGD2UZ5KbcVylfP1vX3oQZj9O+ytRGW37qiuAqjkuLZ73gJt7
> Xlz/6hAwxq+RMsfysJQitdytAcZj/BZQs3OesvcYxSpG9M2zOs3y6Pi+V7ieRk+i
> GbwGFzlGzmyA8LWdpgWFNHjGPlGwa04ALtp/zN6MoovULZs9XskUd3PBM622roJ2
> A+BUrr1GHo8nbcnStcTdL9JQuyrjFPOyyT+FUQR0pWk/PQKutpMzqoKYgK/CWcBv
> bxiREyfCOxTMLKkWXp4tZV6zMakdk+/srbPJbW35HS7PJT6iTP1ldWjh2hw4XXbD
> Jn1OXXJQZ6AHDPGMpKSAvVeCQre/jb6yvFhsgHYz1VjZs5dIw8kqgy5AZrgnjwcX
> 9azk5oNJon6AplWbnN0QVddP+rmxgiPwyvu7ywgxrlgdU3ykazo=
> =h6fX
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Guang

RE: Problem enabling SSLv3 in Tomcat 8.5.15

[Marc Dorsa]

> Hi Mark,
> 
> When can we expect a Tomcat 8.5.x release with SSLv3 support re-enabled?  
> (This feature is critical for our product and is needed ASAP.)

Releases are typically monthly.

We've had a patch of regressions in releases which has delayed things
for the July release.

The August release vote passed yesterday and I expect to be making the
formal announcement later today.

Mark
--

Thanks Mark,

FYI, I've tested and verified SSLv3 works in Tomcat 8.5.20.

I'm a happy camper. :)

Marc

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

[ANN] Apache Tomcat 8.5.20 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.20.

Tomcat 8.x users should normally be using 8.5.x releases in preference
to 8.0.x releases.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and Java Authentication Service Provider Interface for
Containers technologies.

Apache Tomcat 8.5.x is intended to replace 8.0.x and includes new
features pulled forward from the 9.0.x branch. The notable changes since
8.5.16 include:

- Add the ability to set the defaults used by the Windows installer from
  a configuration file. Patch provided by Sandra Madden.

- Add support to the WebSocket client for following redirects when
  attempting to establish a WebSocket connection. Patch provided by J
  Fernandez.

- Add support for the %X pattern in the AccessLogValve that reports the
  connection status at the end of the request. Patch provided by Zemian
  Deng.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-8.5-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team


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

[ANN] Apache Tomcat 9.0.0.M26 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.0.M26.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.0.M26 is a milestone release of the 9.0.x branch and
has been made to provide users with early access to the new features in
Apache Tomcat 9.0.x so that they may provide feedback. The notable
changes compared to 9.0.0.M22 include:

- When generating JSP runtime error messages that quote the relevant JSP
  source code, switch from using the results of the JSP page parsing
  process to using the JSR 045 source map data to identify the correct
  part of the JSP source from the stack trace. This significantly
  reduces the memory footprint of Jasper in development mode, provides a
  small performance improvement for error page generation and enables
  source quotes to continue to be provided after a Tomcat restart.

- Add LoadBalancerDrainingValve, a Valve designed to reduce the amount
  of time required for a node to drain its authenticated users

- Improve the Default Servlet's handling of static files when the file
  encoding is not compatible with the required response encoding.

- Add support for a Tomcat specific deployment descriptor,
  /WEB-INF/tomcat-web.xml. This descriptor has an identical format to
  /WEB-INF/web.xml. The Tomcat descriptor takes precedence over any
  settings in conf/web.xml but does not take precedence over any
  settings in /WEB-INF/web.xml.

- Add ExtractingRoot, a new WebResourceRoot implementation that extracts
  JARs to the work directory for improved performance when deploying
  packed WAR files.

- Add support to the WebSocket client for following redirects when
  attempting to establish a WebSocket connection. Patch provided by J
  Fernandez.

- Add support for the %X pattern in the AccessLogValve that reports the
  connection status at the end of the request. Patch provided by Zemian
  Deng.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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

Re: [OT] Session timeout despite user activity - websockets on Tomcat 8.5.16

[Mark Thomas]

On 09/08/17 17:46, Christopher Schultz wrote:

> Websocket ignoramus, here. Is there a way for (websocket) application
> code on the server side to trigger a "touch" of the HttpSession that
> is linked with the connection? Or is the problem that the websocket
> connection and the HTTP connection are essentially independent?

Through standard APIs, no.

You can get a reference to the session object during the initial
handshake but you'd have to keep a reference to it and then cast it to
an internal Tomcat object and poke around via reflection to get Tomcat's
internal session object and call access().

If the Servlet EG could be convinced to add an access() method... (this
would have to wait until Servlet 4.next / Java EE 9)

We could provide an internal API that would make this a lot easier
(still requires casting but no reflection). That assumes it is always
safe to let an application update a session's last access time. I can't
think of a good reason not to allow this.

Mark

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

Re: [OT] Session timeout despite user activity - websockets on Tomcat 8.5.16

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/9/17 11:35 AM, Mark Thomas wrote:
> On 09/08/17 16:09, David Wall wrote:
>> We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and 
>> Atmosphere Websockets.
>> 
>> We have had reports of sessions logging out while users are
>> active with our Vaadin-based application.  This has been
>> frustrating as we can't seem to track down why Tomcat's session
>> is not being updated, but figure it's something to do with the
>> websockets/push not updating Tomcat reliably.
>> 
>> Our app shows a "last sent to server" timestamp that seems to
>> keep current with user activity, updating as the user clicks on
>> buttons, checkboxes, etc.
>> 
>> We also have a "list of active sessions" screen that shows all
>> active sessions including the HttpSession.getCreationTime() and 
>> HttpSession.getLastAccessedTime().  We see it appears as if the
>> last accessed time stops being updated when using simple forms
>> that perhaps update via websockets rather than HTTP requests.
>> Our "last sent to server" timestamp shows each of these clicks
>> updating it, but the HttpSession.getLastAccessedTime() is not
>> updating.
>> 
>> Is there something about push/websockets or anything else that
>> would cause the HttpSession access time not to update?  I don't
>> think we have a way to update it ourselves as I believe it's
>> managed by Tomcat itself, but as Tomcat is handling the websocket
>> requests, it's unclear why they are not tied to the HttpSession.
>> 
>> Anybody have any ideas?  Thanks as we have a lot of frustrated
>> users who would love for us to find out what's going astray.
> 
> What you are seeing is expected behaviour. This was discussed in
> the WebSocket EG. The short version is: - WebSocket requests don't
> update the session's last accessed time - you need an HTTP request
> from the browser to update the session's last accessed time (and
> update the expiry time of the browser's session cookie) - so the
> application has to do periodic HTTP requests.
> 
> You can reduce the frequency of these requests by extending the
> session timeout (remembering you need an HTTP request after this to
> update the browser's cookie). You then need to be careful to reduce
> the timeout again once WebSocket comms end.

Websocket ignoramus, here. Is there a way for (websocket) application
code on the server side to trigger a "touch" of the HttpSession that
is linked with the connection? Or is the problem that the websocket
connection and the HTTP connection are essentially independent?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmLPEUACgkQHPApP6U8
pFjVpRAAhIk//uWfkihpjwqp75MwDqe4mlAN3zbdvLoa4EU0QJyA8fZRnIFuO7Gg
ksQYycpuGniEMPQH+l4Mb3T5/KogTkY3DZrBRh7vN+8oA3ELayuqTxDAdNjjsnmg
uKWeYv3obL8pZQuSb5hVFXx4Dfe6pAXWk7CwuHls5Cs97lRqvN9C5lQM1QPArPpt
nqNnDUm7HHmrSZVo82bdJxgXfpRXnoIg5qie3wGURHzdQK4JZGpZY7jJDAmM/HTW
QNHg2saIFR1ce5YdGD2UZ5KbcVylfP1vX3oQZj9O+ytRGW37qiuAqjkuLZ73gJt7
Xlz/6hAwxq+RMsfysJQitdytAcZj/BZQs3OesvcYxSpG9M2zOs3y6Pi+V7ieRk+i
GbwGFzlGzmyA8LWdpgWFNHjGPlGwa04ALtp/zN6MoovULZs9XskUd3PBM622roJ2
A+BUrr1GHo8nbcnStcTdL9JQuyrjFPOyyT+FUQR0pWk/PQKutpMzqoKYgK/CWcBv
bxiREyfCOxTMLKkWXp4tZV6zMakdk+/srbPJbW35HS7PJT6iTP1ldWjh2hw4XXbD
Jn1OXXJQZ6AHDPGMpKSAvVeCQre/jb6yvFhsgHYz1VjZs5dIw8kqgy5AZrgnjwcX
9azk5oNJon6AplWbnN0QVddP+rmxgiPwyvu7ywgxrlgdU3ykazo=
=h6fX
-END PGP SIGNATURE-

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

Re: Session timeout despite user activity - websockets on Tomcat 8.5.16

[David Wall]

On 8/9/17 8:35 AM, Mark Thomas wrote:

On 09/08/17 16:09, David Wall wrote:

We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and
Atmosphere Websockets.

We have had reports of sessions logging out while users are active with
our Vaadin-based application.  This has been frustrating as we can't
seem to track down why Tomcat's session is not being updated, but figure
it's something to do with the websockets/push not updating Tomcat reliably.

Our app shows a "last sent to server" timestamp that seems to keep
current with user activity, updating as the user clicks on buttons,
checkboxes, etc.

We also have a "list of active sessions" screen that shows all active
sessions including the HttpSession.getCreationTime() and
HttpSession.getLastAccessedTime().  We see it appears as if the last
accessed time stops being updated when using simple forms that perhaps
update via websockets rather than HTTP requests.  Our "last sent to
server" timestamp shows each of these clicks updating it, but the
HttpSession.getLastAccessedTime() is not updating.

Is there something about push/websockets or anything else that would
cause the HttpSession access time not to update?  I don't think we have
a way to update it ourselves as I believe it's managed by Tomcat itself,
but as Tomcat is handling the websocket requests, it's unclear why they
are not tied to the HttpSession.

Anybody have any ideas?  Thanks as we have a lot of frustrated users who
would love for us to find out what's going astray.

What you are seeing is expected behaviour. This was discussed in the
WebSocket EG. The short version is:
- WebSocket requests don't update the session's last accessed time
- you need an HTTP request from the browser to update the session's
   last accessed time (and update the expiry time of the browser's
   session cookie)
- so the application has to do periodic HTTP requests.

You can reduce the frequency of these requests by extending the session
timeout (remembering you need an HTTP request after this to update the
browser's cookie). You then need to be careful to reduce the timeout
again once WebSocket comms end.

Mark


Thanks, Mark.  Let me check but it is my impression that a HEARTBEAT 
type request is sent every 5 minutes, but I'll investigate further. You 
at least answered my question and we should be able to find a solution 
of that nature.


David

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

Re: Session timeout despite user activity - websockets on Tomcat 8.5.16

[Mark Thomas]

On 09/08/17 16:09, David Wall wrote:
> We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and
> Atmosphere Websockets.
> 
> We have had reports of sessions logging out while users are active with
> our Vaadin-based application.  This has been frustrating as we can't
> seem to track down why Tomcat's session is not being updated, but figure
> it's something to do with the websockets/push not updating Tomcat reliably.
> 
> Our app shows a "last sent to server" timestamp that seems to keep
> current with user activity, updating as the user clicks on buttons,
> checkboxes, etc.
> 
> We also have a "list of active sessions" screen that shows all active
> sessions including the HttpSession.getCreationTime() and
> HttpSession.getLastAccessedTime().  We see it appears as if the last
> accessed time stops being updated when using simple forms that perhaps
> update via websockets rather than HTTP requests.  Our "last sent to
> server" timestamp shows each of these clicks updating it, but the
> HttpSession.getLastAccessedTime() is not updating.
> 
> Is there something about push/websockets or anything else that would
> cause the HttpSession access time not to update?  I don't think we have
> a way to update it ourselves as I believe it's managed by Tomcat itself,
> but as Tomcat is handling the websocket requests, it's unclear why they
> are not tied to the HttpSession.
> 
> Anybody have any ideas?  Thanks as we have a lot of frustrated users who
> would love for us to find out what's going astray.

What you are seeing is expected behaviour. This was discussed in the
WebSocket EG. The short version is:
- WebSocket requests don't update the session's last accessed time
- you need an HTTP request from the browser to update the session's
  last accessed time (and update the expiry time of the browser's
  session cookie)
- so the application has to do periodic HTTP requests.

You can reduce the frequency of these requests by extending the session
timeout (remembering you need an HTTP request after this to update the
browser's cookie). You then need to be careful to reduce the timeout
again once WebSocket comms end.

Mark

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

Session timeout despite user activity - websockets on Tomcat 8.5.16

[David Wall]

We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and 
Atmosphere Websockets.


We have had reports of sessions logging out while users are active with 
our Vaadin-based application.  This has been frustrating as we can't 
seem to track down why Tomcat's session is not being updated, but figure 
it's something to do with the websockets/push not updating Tomcat reliably.


Our app shows a "last sent to server" timestamp that seems to keep 
current with user activity, updating as the user clicks on buttons, 
checkboxes, etc.


We also have a "list of active sessions" screen that shows all active 
sessions including the HttpSession.getCreationTime() and 
HttpSession.getLastAccessedTime().  We see it appears as if the last 
accessed time stops being updated when using simple forms that perhaps 
update via websockets rather than HTTP requests.  Our "last sent to 
server" timestamp shows each of these clicks updating it, but the 
HttpSession.getLastAccessedTime() is not updating.


Is there something about push/websockets or anything else that would 
cause the HttpSession access time not to update?  I don't think we have 
a way to update it ourselves as I believe it's managed by Tomcat itself, 
but as Tomcat is handling the websocket requests, it's unclear why they 
are not tied to the HttpSession.


Anybody have any ideas?  Thanks as we have a lot of frustrated users who 
would love for us to find out what's going astray.


David


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

Re: Small question on mod_jk load balancing methon "Next"

[Rainer Jung]

Am 09.08.2017 um 11:50 schrieb Martin Knoblauch:

On Fri, Aug 4, 2017 at 11:47 PM, Rainer Jung 
wrote:


Hi Martin,

Am 04.08.2017 um 10:53 schrieb Martin Knoblauch:


Hi,

 just need some clarification on the mod_jk load blanacing method "Next".
The documentation states:

"If method is set to N[ext] the balancer will again use the number of
sessions to find the best worker. All remarks concerning the Session
method
apply as well. The difference to the Session method is how the session
count is handled in the sliding time window. The Next method does not
divide by 2, instead it subtracts the current minimum number. This should
effectively result in a round-robin session balancing, thus the name Next.
Under high load, the two session balancing methods will result in a
similar
distribution, but Next will be better if you need to distribute small
numbers of sessions. "

 What exactly is the "current minimum number"? How is the minimum taken?
From all workers in the balancer set, or only the ACTive ones? I know, I
should look it up in the code :-)



I looked up the code I wrote 6 years ago.

First: when using the session base lb methods, mod_jk needs to estimate
session counts. No lb method of mod_jk contacts the backends to get real
data, instead mod_jk uses the request info it sees to estimate the backend
situation.

For session based methods, mod_jk counts requests, that do not include a
session id assuming that those are exactly the ones that create new
sessions. Of course:

a) a session id can be outdated, meaning mod_jk would not count the
request as session creating but in fact it would create a new one. One can
at least configure mod_jk to be aware of login pages which will always
create a new session (see http://tomcat.apache.org/conne
ctors-doc/reference/uriworkermap.html and http://tomcat.apache.org/conne
ctors-doc/reference/apache.html and there look for "sticky_ignore").

b) a request without a session ID might not actually create a session,
depending on app details. There are additional config options to teach
mod_jk which URIs do not create sessions (see
http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html and
http://tomcat.apache.org/connectors-doc/reference/apache.html and there
look for "stateless").

c) sessions time out in backends and users can log out. mod_jk does not
track that. One can remove the session cookie during the logout, so that
the "new" requests from that user will be counted by the mod_jk session
counter.

Because of these problems I typically recommend to stick to the default lb
method (request counting, not session counting). But sometimes apps have
resource usage dominated by sessions and then a "session" based lb method
can help, especially if you find a configuration which keeps the effect of
a)-c) above small.

Since all counting methods, not only session based ones, would count stuff
since the last restart of mod_jk, but the current backend load situation
depends much more on stuff that happened recently, we try to get rid of
past counts by reducing the counters regularly. By default this happens
once per minute and is done in a way that the counters are divided by 2
once per minute. That way old counter increases contribute less and less to
the current counter value. For the session based method this would mean we
assume half of the counted sessions die after one minute, 50% of the rest
during the next minute etc. Note that the counters are integers, so e.g. a
counter value of 1 will after division by 2 result in a new value 0. Most
often that is no problem, because on a loaded system numbers are big and
rounding down doesn't change a lot.

The next request without session id will be send to the worker with the
smallest such "session" counter.

The "Next" message varies that procedure by not dividing by 2 every
minute, but instead subtracting the minimum value of the backend counters.
Assume after the first minute, your 4 backends have "session" counters 2,
3, 3 and 2. Then the minimum is 2, so after the minute we correct the
values to 0, 1, 1 and 0. Then we add for the next minute new sessions to
that counter and again subtract the new minimum etc.

When would that be helpful? It was for an application with really huge
sessions but small session numbers. There was a risk that if for a minute
only 0 or one sessions were created on the backends, after dividing by 2
all workers were again 0.

You can actually track the counters via the status worker, were they are
exposed as column "V" (load balancer value).

Regards,

Rainer



Hi Rainer,

 thanks a lot for the comprehensive write-up. Very useful. Just it does not
answer my question on which workers are considered when determining the
"minimum number" :-) Will all workers be considered, or only those in ACT
state?


Ah, I didn't get that question, because you didn't mention the worker 
states.


The current minimum will be taken over all workers which are in 
activation state 

Re: Tomcat8 - How to configure ssl certificates for both https and two-way authentication

[Mark Thomas]

On 09/08/17 12:24, Senthil Kumar wrote:
> Mark,
> 
> Tomcat version is 8.0.39.
> 
> I have to use both server certificate (.pfx) and service certificate as
> keystore. Do I need to convert PFX format certificate to JKS format. How to
> configure more than on private certificate in keystore.

The setenv.sh settings shouldn't interfere with the Tomcat connector but
to be sure I suggest the following:

- comment out the setenv.sh settings
- start Tomcat
- test https on port 443 and report and errors including those in the
  logs

Once port 443 is working then uncomment the settings in setenv and check
port 433 still works.

Mark

> 
> Senthil
> 
> On Wed, Aug 9, 2017 at 1:39 AM, Mark Thomas  wrote:
> 
>> On 08/08/17 21:03, dsenthil...@gmail.com wrote:
>>>
 Hello,

 I have configured ssl certificates for below requirements:

 1. Tomcat server certificate configuration in 'server.xml' file to run
>> tomcat server on port 443 and https

  > minSpareThreads="25"
maxSpareThreads="75" enableLookups="false"
>> disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
>> SSLEnabled="true" clientAuth="false"
sslProtocol="TLSv1.2" 
 ciphers="TLS_RSA_WITH_AES_256_CBC_SHA256"
>> keystoreFile="Tomcat.HostName.pfx" keystorePass="password"
keystoreType="PKCS12" />

 2. Service certificate configuration in 'setenv.sh' file for the
>> two-way ssl authentication for the connection to MQ / Soap service servers.

 export JAVA_OPTS='-Djavax.net.ssl.keyStore=ServiceCertificate.p12
>> -Djavax.net.ssl.keyStorePassword=password 
>> -Djavax.net.ssl.trustStore=clienttruststore.jks
>> -Djavax.net.ssl.trustStorePassword=changeit'


 But It looks like the service certificate configured (for the two-way
>> ssl handshake with MQ and Soap service servers) in 'setenv.sh' file is
>> overwriting the tomcat server ssl configuration configured in 'server.xml'
>> and subsequently tomcat server is down for https and port 443.

 Can someone recommend suitable tomcat config to fix this issue. The
>> tomcat config should support both https (port 443) and two-ways ssl
>> handshake with other servers.
>>
>> Tomcat version?
>>
>>
>> -
>> 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: Problem enabling SSLv3 in Tomcat 8.5.15

[Mark Thomas]

> Hi Mark,
> 
> When can we expect a Tomcat 8.5.x release with SSLv3 support re-enabled?  
> (This feature is critical for our product and is needed ASAP.)

Releases are typically monthly.

We've had a patch of regressions in releases which has delayed things
for the July release.

The August release vote passed yesterday and I expect to be making the
formal announcement later today.

Mark

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

finally websockets close correctly

[Cristian Lorenzetto]

oh finally you resolved the problem with websockets  when is closed... when
i told you 2 years ago ... i didnt hear me

Re: Tomcat8 - How to configure ssl certificates for both https and two-way authentication

[Senthil Kumar]

Mark,

Tomcat version is 8.0.39.

I have to use both server certificate (.pfx) and service certificate as
keystore. Do I need to convert PFX format certificate to JKS format. How to
configure more than on private certificate in keystore.

Senthil

On Wed, Aug 9, 2017 at 1:39 AM, Mark Thomas  wrote:

> On 08/08/17 21:03, dsenthil...@gmail.com wrote:
> >
> >> Hello,
> >>
> >> I have configured ssl certificates for below requirements:
> >>
> >> 1. Tomcat server certificate configuration in 'server.xml' file to run
> tomcat server on port 443 and https
> >>
> >>   minSpareThreads="25"
> >>maxSpareThreads="75" enableLookups="false"
> disableUploadTimeout="true"
> >>acceptCount="100" scheme="https" secure="true"
> SSLEnabled="true" clientAuth="false"
> >>sslProtocol="TLSv1.2" 
> >> ciphers="TLS_RSA_WITH_AES_256_CBC_SHA256"
> keystoreFile="Tomcat.HostName.pfx" keystorePass="password"
> >>keystoreType="PKCS12" />
> >>
> >> 2. Service certificate configuration in 'setenv.sh' file for the
> two-way ssl authentication for the connection to MQ / Soap service servers.
> >>
> >> export JAVA_OPTS='-Djavax.net.ssl.keyStore=ServiceCertificate.p12
> -Djavax.net.ssl.keyStorePassword=password 
> -Djavax.net.ssl.trustStore=clienttruststore.jks
> -Djavax.net.ssl.trustStorePassword=changeit'
> >>
> >>
> >> But It looks like the service certificate configured (for the two-way
> ssl handshake with MQ and Soap service servers) in 'setenv.sh' file is
> overwriting the tomcat server ssl configuration configured in 'server.xml'
> and subsequently tomcat server is down for https and port 443.
> >>
> >> Can someone recommend suitable tomcat config to fix this issue. The
> tomcat config should support both https (port 443) and two-ways ssl
> handshake with other servers.
>
> Tomcat version?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Small question on mod_jk load balancing methon "Next"

[Martin Knoblauch]

On Fri, Aug 4, 2017 at 11:47 PM, Rainer Jung 
wrote:

> Hi Martin,
>
> Am 04.08.2017 um 10:53 schrieb Martin Knoblauch:
>
>> Hi,
>>
>>  just need some clarification on the mod_jk load blanacing method "Next".
>> The documentation states:
>>
>> "If method is set to N[ext] the balancer will again use the number of
>> sessions to find the best worker. All remarks concerning the Session
>> method
>> apply as well. The difference to the Session method is how the session
>> count is handled in the sliding time window. The Next method does not
>> divide by 2, instead it subtracts the current minimum number. This should
>> effectively result in a round-robin session balancing, thus the name Next.
>> Under high load, the two session balancing methods will result in a
>> similar
>> distribution, but Next will be better if you need to distribute small
>> numbers of sessions. "
>>
>>  What exactly is the "current minimum number"? How is the minimum taken?
>> From all workers in the balancer set, or only the ACTive ones? I know, I
>> should look it up in the code :-)
>>
>
> I looked up the code I wrote 6 years ago.
>
> First: when using the session base lb methods, mod_jk needs to estimate
> session counts. No lb method of mod_jk contacts the backends to get real
> data, instead mod_jk uses the request info it sees to estimate the backend
> situation.
>
> For session based methods, mod_jk counts requests, that do not include a
> session id assuming that those are exactly the ones that create new
> sessions. Of course:
>
> a) a session id can be outdated, meaning mod_jk would not count the
> request as session creating but in fact it would create a new one. One can
> at least configure mod_jk to be aware of login pages which will always
> create a new session (see http://tomcat.apache.org/conne
> ctors-doc/reference/uriworkermap.html and http://tomcat.apache.org/conne
> ctors-doc/reference/apache.html and there look for "sticky_ignore").
>
> b) a request without a session ID might not actually create a session,
> depending on app details. There are additional config options to teach
> mod_jk which URIs do not create sessions (see
> http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html and
> http://tomcat.apache.org/connectors-doc/reference/apache.html and there
> look for "stateless").
>
> c) sessions time out in backends and users can log out. mod_jk does not
> track that. One can remove the session cookie during the logout, so that
> the "new" requests from that user will be counted by the mod_jk session
> counter.
>
> Because of these problems I typically recommend to stick to the default lb
> method (request counting, not session counting). But sometimes apps have
> resource usage dominated by sessions and then a "session" based lb method
> can help, especially if you find a configuration which keeps the effect of
> a)-c) above small.
>
> Since all counting methods, not only session based ones, would count stuff
> since the last restart of mod_jk, but the current backend load situation
> depends much more on stuff that happened recently, we try to get rid of
> past counts by reducing the counters regularly. By default this happens
> once per minute and is done in a way that the counters are divided by 2
> once per minute. That way old counter increases contribute less and less to
> the current counter value. For the session based method this would mean we
> assume half of the counted sessions die after one minute, 50% of the rest
> during the next minute etc. Note that the counters are integers, so e.g. a
> counter value of 1 will after division by 2 result in a new value 0. Most
> often that is no problem, because on a loaded system numbers are big and
> rounding down doesn't change a lot.
>
> The next request without session id will be send to the worker with the
> smallest such "session" counter.
>
> The "Next" message varies that procedure by not dividing by 2 every
> minute, but instead subtracting the minimum value of the backend counters.
> Assume after the first minute, your 4 backends have "session" counters 2,
> 3, 3 and 2. Then the minimum is 2, so after the minute we correct the
> values to 0, 1, 1 and 0. Then we add for the next minute new sessions to
> that counter and again subtract the new minimum etc.
>
> When would that be helpful? It was for an application with really huge
> sessions but small session numbers. There was a risk that if for a minute
> only 0 or one sessions were created on the backends, after dividing by 2
> all workers were again 0.
>
> You can actually track the counters via the status worker, were they are
> exposed as column "V" (load balancer value).
>
> Regards,
>
> Rainer
>
>
Hi Rainer,

 thanks a lot for the comprehensive write-up. Very useful. Just it does not
answer my question on which workers are considered when determining the
"minimum number" :-) Will all workers be considered, or only those in ACT
state?

 The reason why I am 

Re: Small question on mod_jk load balancing methon "Next"

[Martin Knoblauch]

On Fri, Aug 4, 2017 at 11:49 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Martin,
>
> On 8/4/17 4:53 AM, Martin Knoblauch wrote:
> > Hi,
> >
> > just need some clarification on the mod_jk load blanacing method
> > "Next". The documentation states:
> >
> > "If method is set to N[ext] the balancer will again use the number
> > of sessions to find the best worker. All remarks concerning the
> > Session method apply as well. The difference to the Session method
> > is how the session count is handled in the sliding time window. The
> > Next method does not divide by 2, instead it subtracts the current
> > minimum number. This should effectively result in a round-robin
> > session balancing, thus the name Next. Under high load, the two
> > session balancing methods will result in a similar distribution,
> > but Next will be better if you need to distribute small numbers of
> > sessions. "
> >
> > What exactly is the "current minimum number"? How is the minimum
> > taken?
> >> From all workers in the balancer set, or only the ACTive ones?
>
> I don't know for sure, but just in case this is a language issue, I
> believe it means it will subtract the "lowest number of sessions
> amongst all active workers". So if you had workers 1, 2, and 3 with
> 45, 50, and 55 sessions respectively, it will subtract the value 45
> from all worker session counts to determine the priority for which
> node will get the next session.
>
>
 Now my question was: which workers are considered for the lowest number of
sessions. All of them, or only the ones in ACT state?

Thanks
Martin


>
>


-- 
--
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de