On 10/03/2024 16:59, Manak Bisht wrote:
On Fri, Feb 9, 2024 at 4:45 PM Mark Thomas wrote:
Using 0.0.0.0 as the address for the receiver is going to cause
problems. I see similar issues with 11.0.x as 8.5.x. I haven't dug too
deeply into things as a) I am short of time and b) I'm not convinced
On Fri, Feb 9, 2024 at 4:45 PM Mark Thomas wrote:
> Using 0.0.0.0 as the address for the receiver is going to cause
> problems. I see similar issues with 11.0.x as 8.5.x. I haven't dug too
> deeply into things as a) I am short of time and b) I'm not convinced
> this should/could work anyway.
>
>
I would suggest focusing on Docker networking rather than Tomcat. My
guess is that how that works will inform your Tomcat configuration. You
might also try first getting it to work with two Docker instances on a
single machine.
-Terence Bandoian
On 3/1/2024 11:59 AM, Manak Bisht wrote:
I am
I am fairly certain now that the docker container is the problem. I am
unable to replicate the issue without it. Using the hostname/IP address of
the host (tomcat/ip) for the receiver always causes the following problem,
01-Mar-2024 22:30:32.315 INFO [main]
org.apache.catalina.tribes.transport.Rece
Hello Dear
Thanks for your reply
l would use this opportunity to briefly introduce our company, Bigly
Technologies Thailand, We are one of the leading importers in Asia , and
the Middle East on general Goods and Equipment.
On behalf of Bigly Technologies Thailand, this is the samples of the
produ
No devices in-between, browser to local host. Good feedback though, I'll
try to reproduce with the snake app
Thanks!
On Fri, Feb 16, 2024, 2:47 PM Chuck Caldarale wrote:
>
> > On Feb 16, 2024, at 11:31, Mark Thomas wrote:
> >
> > On 09/02/2024 13:47, Alex O'Ree wrote:
> >> I've been experimenti
> On Feb 16, 2024, at 11:31, Mark Thomas wrote:
>
> On 09/02/2024 13:47, Alex O'Ree wrote:
>> I've been experimenting with tomcat 9.x in seeing how long i can get a web
>> socket session to last. I'm currently struggling to get past 30 minutes or
>> so. Looking for guidance on how to best incre
On 09/02/2024 13:47, Alex O'Ree wrote:
I've been experimenting with tomcat 9.x in seeing how long i can get a web
socket session to last. I'm currently struggling to get past 30 minutes or
so. Looking for guidance on how to best increase this or if this is a bad
idea.
Here's the current configur
Manak,
On 2/12/24 10:33, Manak Bisht wrote:
Chris,
On Mon, 12 Feb 2024, 20:52 Christopher Schultz, <
ch...@christopherschultz.net> wrote:
I wouldn't refuse to configure, since anyone using
0.0.0.0 with /separate/ hosts wouldn't experience this problem.
I am using separate hosts (two docker
Chris,
On Mon, 12 Feb 2024, 20:52 Christopher Schultz, <
ch...@christopherschultz.net> wrote:
> I wouldn't refuse to configure, since anyone using
> 0.0.0.0 with /separate/ hosts wouldn't experience this problem.
I am using separate hosts (two docker containers on two different machines)
in my
Mark,
On 2/9/24 06:14, Mark Thomas wrote:
With the Receiver using address="0.0.0.0" I see the same issues you do.
I'm not yet convinced that is a bug.
If this is known to essentially always not-work... should we log
something at startup? I wouldn't refuse to configure, since anyone using
0.0
I've been experimenting with tomcat 9.x in seeing how long i can get a web
socket session to last. I'm currently struggling to get past 30 minutes or
so. Looking for guidance on how to best increase this or if this is a bad
idea.
Here's the current configuration and what i've tried thus far:
The
On 09/02/2024 07:51, Manak Bisht wrote:
On Fri, Feb 9, 2024 at 3:25 AM Mark Thomas wrote:
Same JRE?
Yes, 8.0.402
Generally, I wouldn't use 0.0.0.0, I'd use a specific IP address. I'm
not sure how the clustering would behave with 0.0.0.0
Using 0.0.0.0 as the address for the receiver is
On Fri, Feb 9, 2024 at 3:25 AM Mark Thomas wrote:
> Same JRE?
>
Yes, 8.0.402
Generally, I wouldn't use 0.0.0.0, I'd use a specific IP address. I'm
> not sure how the clustering would behave with 0.0.0.0
>
That's the problem really. Using the DNS name or IP address causes the
following error -
pecific IP address. I'm
not sure how the clustering would behave with 0.0.0.0
Mark
Sincerely,
Manak Bisht
On Fri, Feb 2, 2024 at 9:41 PM Mark Thomas wrote:
On 31/01/2024 13:33, Manak Bisht wrote:
I tried tweaking all the settings that I could think of but I am unable
to
sync sess
sht wrote:
> > I tried tweaking all the settings that I could think of but I am unable
> to
> > sync sessions on restart even on a stock Tomcat 8.5.98 installation using
> > your provided war. I am unable to identify whether this is actually a bug
> > or something wrong with
On 31/01/2024 13:33, Manak Bisht wrote:
I tried tweaking all the settings that I could think of but I am unable to
sync sessions on restart even on a stock Tomcat 8.5.98 installation using
your provided war. I am unable to identify whether this is actually a bug
or something wrong with my
I tried tweaking all the settings that I could think of but I am unable to
sync sessions on restart even on a stock Tomcat 8.5.98 installation using
your provided war. I am unable to identify whether this is actually a bug
or something wrong with my configuration (this is far more likely). Could
Hi Mark,
I tried running your *cluster-test* war example on a stock 8.5.98
installation, however, I am facing the same issue. Session sync does not
trigger on restarting a node. Could you please share your configuration?
Sincerely,
Manak Bisht
Thanks for going the extra mile to help me out on this. I really appreciate
it.
As far as I am aware, the auto detection of local member is only available
post v9.0.17 and the tag was added in v8.5.1. Unfortunately,
I happen to be working in an environment where 8.5.0 is the highest non-EOL
versio
/cluster-test.war
Starting both both nodes and connecting directly to each manager
instance shows no sessions in cluster-test as expected.
Requesting the cluster index page via httpd triggers the creation of a
single session in cluster-test. Requests alternate between node 1 and
node 2 as expected
uests with the same
> JSESSIONID being served successfully by both tomcats. This leads me to
> conclude that session replication is working as expected when both nodes
> are up.
>
> However, when I restart any one of them, the newly restarted tomcat is
> unable to serve reque
.
However, when I restart any one of them, the newly restarted tomcat is
unable to serve requests from old sessions. The logs indicate that node
discovering is working but the session sync timeouts. New logins/sessions
work just fine though, implying that replication is working successfully
again
Stephane,
On 5/25/23 12:44, Stephane Passignat wrote:
Hello,
I would like to open multiple concurrent session in a web-application
for one user. As far as I understand, the sessionid is stored in the
cookie and the cookie is associated to the server (http://localhost:8080/).
So if I open a
Am I understanding your use case right?
You need a particular user to have multiple sessions in the same browser?
or are you saying you need multiple users to be able to log into your
application in the same browser?
On Thu, May 25, 2023 at 12:45 PM Stephane Passignat
wrote:
> Hello,
&g
Hello,
I would like to open multiple concurrent session in a web-application
for one user. As far as I understand, the sessionid is stored in the
cookie and the cookie is associated to the server (http://localhost:8080/).
So if I open a new browser window with the URL, I reach the same page
Chew Kok,
On 4/5/23 20:31, Chew Kok Hoor wrote:
Thanks for your suggestion. Do you have any url reference / resource
related to getting JMX from within the same JVM?
I am currently accessing from a servlet when verifying sessions.
You need to know how to access the JMX management system in
Hi Chris,
Thanks for your suggestion. Do you have any url reference / resource
related to getting JMX from within the same JVM?
I am currently accessing from a servlet when verifying sessions.
Thanks.
Regards,
Kok Hoor
On Thu, Apr 6, 2023, 1:56 AM Christopher Schultz <
ontrol access to Servlets that implement
ContainerServlet.
The ContainerServlet interface is one way to access Tomcat's internals.
Another option is reflection.
You can also get sessions via JMX within the same JVM.
-chris
On 02/04/2023 13:44, Chew Kok Hoor wrote:
Hi,
As part of a way to prevent concurrent login, and to re-assign a
session back to a request based on JWT token (for clients that cannot pass
us cookies), we need to access to the 'findSession' and 'findSessions' in
org.apache.catalina.Manager.
Hi,
As part of a way to prevent concurrent login, and to re-assign a
session back to a request based on JWT token (for clients that cannot pass
us cookies), we need to access to the 'findSession' and 'findSessions' in
org.apache.catalina.Manager.
Is it true the only way to get the manager
Il 30/07/2021 14:54, Konstantin Kolinko ha scritto:
Additional note: the "backgroundProcessorDelay" on a Context can be
used to make a web application use its own background thread (instead
of reusing the one inherited from its parent container). It won't
help with fixing a deadlock in a part
ring sessionUnbound and
> >> unboundEvents.
> >>
> >> So the background process killing the sessions is stuck as well.
> >
> > This is a very easy problem to encounter. Session event-handlers
> > really need to be bulletproof and execute very quickly.
> >
>
on a MultiThreadedHttpConnectionManager during sessionUnbound and
unboundEvents.
So the background process killing the sessions is stuck as well.
This is a very easy problem to encounter. Session event-handlers
really need to be bulletproof and execute very quickly.
If you need a long-running process to trigger, u
Ivano,
On 7/23/21 02:20, Ivano Luberti wrote:
I have found the issue: one of the webapps has several thread locked on
a MultiThreadedHttpConnectionManager during sessionUnbound and
unboundEvents.
So the background process killing the sessions is stuck as well.
This is a very easy problem
I have found the issue: one of the webapps has several thread locked on
a MultiThreadedHttpConnectionManager during sessionUnbound and
unboundEvents.
So the background process killing the sessions is stuck as well.
Thanks for your support.
Il 21/07/2021 18:13, Mark Thomas ha scritto:
On
On 21/07/2021 16:00, Ivano Luberti wrote:
Il 21/07/2021 16:44, Mark Thomas ha scritto:
Take 3 thread dumps 5 seconds apart and post them here.
How to take thread dumps?
kill -3 ?
That will work. There are lots of ways. This is most of them:
https://www.baeldung.com/java-thread-dump
Ma
Il 21/07/2021 16:44, Mark Thomas ha scritto:
Take 3 thread dumps 5 seconds apart and post them here.
How to take thread dumps?
kill -3 ?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional comma
this instance.
I have noticed that after a few days tomcat stops killing expired sessions.
Trying to understand where the issue is located , I have enabled debug
logging of org.apache.catalina.session package with:
java.util.logging.ConsoleHandler.level = FINEST
org.apache.catalina.session.
days tomcat stops killing expired sessions.
Trying to understand where the issue is located , I have enabled debug
logging of org.apache.catalina.session package with:
java.util.logging.ConsoleHandler.level = FINEST
org.apache.catalina.session.level = FINEST
So after the latest restart i
sted Manager element.
So, guessing I'm using by default the Standard Manager Implementation,
where does it store active sessions, if it does at all?
Olaf is right. StandardManager keeps active sessions in Memory. However,
when its _Persistence Across Restarts_ features comes into play
(
ntext has no nested Manager element.
>
> So, guessing I'm using by default the Standard Manager Implementation,
> where does it store active sessions, if it does at all?
Without looking it up (thus I could easily be proved wrong): My
assumption is that the active sessions are in memory
as no nested Manager element.
So, guessing I'm using by default the Standard Manager Implementation,
where does it store active sessions, if it does at all?
With this setup, the locations of interest that I found until now are:
/var/lib/tomcat9
/etc/tomcat9
usr/share/tomcat9
var/log/tomcat9
/etc/default/tomcat9
; > I am setting up a tomcat cluster (only two nodes on separate servers)
> > for load-balancing and sessions replication purpose.
> >
> > The session replication is working fine from node1 to node2 (i can see
> > the primary session on node1 and the backup session on node2).
On 16/01/2020 08:11, Bertrand BARRET wrote:
> Hello,
>
> I am setting up a tomcat cluster (only two nodes on separate servers)
> for load-balancing and sessions replication purpose.
>
> The session replication is working fine from node1 to node2 (i can see
> the primary ses
Hello,
I am setting up a tomcat cluster (only two nodes on separate servers)
for load-balancing and sessions replication purpose.
The session replication is working fine from node1 to node2 (i can see
the primary session on node1 and the backup session on node2).
But when the load balancer
On 30/01/2019 01:18, James H. H. Lampert wrote:
> On 1/28/19, 1:21 AM, Mark Thomas wrote:
>> http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Crawler_Session_Manager_Valve
>>
>>
>> Set the crawler user agent and/or crawler IP appropriately so your
>> load-balancer is treated as a web-crawl
On 1/28/19, 1:21 AM, Mark Thomas wrote:
http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Crawler_Session_Manager_Valve
Set the crawler user agent and/or crawler IP appropriately so your
load-balancer is treated as a web-crawler and all those health-checks
will be associated with a singl
ter, that polls the
>>> default landing page of ROOT periodically. Up until a few days
>>> ago, it was polling it every 5 seconds; earlier this week, I cut
>>> it down to every 5 minutes (the maximum); now I've got it at
>>> every 30 seconds.
>>>
>>
ROOT periodically. Up until a few days
>> ago, it was polling it every 5 seconds; earlier this week, I cut
>> it down to every 5 minutes (the maximum); now I've got it at
>> every 30 seconds.
>>
>> If I open the Manager context, I find that it shows (currently)
&g
minutes (the maximum); now I've got it at every 30 seconds.
>
> If I open the Manager context, I find that it shows (currently) around
> 180 sessions for the ROOT context. When it was going every 5 minutes, it
> was showing 18 sessions; when it was going every 5 seconds, it was up
text, I find that it shows (currently) around
180 sessions for the ROOT context. When it was going every 5 minutes, it
was showing 18 sessions; when it was going every 5 seconds, it was up to
over a thousand.
The other two sub-clusters don't have any dangling sessions from their
health-c
s into an error deserializing the "all
sessions" message, all sessions from the one with the error and later
are lost. I realize it must currently be this way because once there is
an error in the serialized stream there is no realistic way to find
where the next session object begins in t
.. 2
big questions/ideas:
1) Any time the DeltaManager runs into an error deserializing the "all
sessions" message, all sessions from the one with the error and later
are lost. I realize it must currently be this way because once there is
an error in the serialized stream there is no re
data
from the "B" server. Any ideas what could be causing this? It seems like
that if there was something in a Session object that was not
Serializable it would not even make it over the wire. Perhaps if
something in a session did not serialize properly?
(From the code, it looks lik
essed...
Thanks for the insights!
Leon
On Mon, Aug 27, 2018 at 9:07 AM Jäkel, Guido wrote:
> Dear Leon,
>
> I suggest to use the Tomcat Manager Application to investigate the session
> data:
>
> * Use the Session Display (/manager/html/sessions?path=/foo) to take a
> lo
Dear Leon,
I suggest to use the Tomcat Manager Application to investigate the session data:
* Use the Session Display (/manager/html/sessions?path=/foo) to take a look on
the different Timers (Creation Time, Last Accessed Time, Used Time, Inactive
Timemm,TTL) or even the session data
* Use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Leon,
On 8/24/18 05:25, Leon Rosenberg wrote:
> one of the systems we are consulting has encountered a strange
> problem. The sessions will build up indefinitely but never expire.
> Then, at one point (at 02am in the night, 19K sessions w
Hi,
one of the systems we are consulting has encountered a strange problem. The
sessions will build up indefinitely but never expire. Then, at one point
(at 02am in the night, 19K sessions would drop at once).
Of course the simplest explanation would be that someone is actively
requests something
On Tue, Jul 31, 2018, 7:42 AM Burghard Britzke
wrote:
> that is, what „transient“ means...
> --
> Gruß
> burghard.britzke
> https://britzke.berlin/
>
> Am 31.07.2018 um 13:39 schrieb Tim K :
>
> On Tue, Jul 31, 2018, 7:31 AM Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
> Am 30
that is, what „transient“ means...
--
Gruß
burghard.britzke
https://britzke.berlin/
> Am 31.07.2018 um 13:39 schrieb Tim K :
>
> On Tue, Jul 31, 2018, 7:31 AM Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
>> Am 30.07.2018 17:57, schrieb Tim K:
>>> On Mon, Jul 30, 2018, 4:26 AM
On Tue, Jul 31, 2018, 7:31 AM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:
> Am 30.07.2018 17:57, schrieb Tim K:
> > On Mon, Jul 30, 2018, 4:26 AM Felix Schumacher <
> > felix.schumac...@internetallee.de> wrote:
> >
> >> Am 27.07.2018 13:36, schrieb Tim K:
> >> > Hello,
> >> >
> >>
Am 30.07.2018 17:57, schrieb Tim K:
On Mon, Jul 30, 2018, 4:26 AM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:
Am 27.07.2018 13:36, schrieb Tim K:
> Hello,
>
> I'm creating a new app under Tomcat 9.0.8 (local dev: windows, live
> servers: linux).
>
> I have successfully created
On Mon, Jul 30, 2018, 4:26 AM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:
> Am 27.07.2018 13:36, schrieb Tim K:
> > Hello,
> >
> > I'm creating a new app under Tomcat 9.0.8 (local dev: windows, live
> > servers: linux).
> >
> > I have successfully created a custom JAAS authenticat
Am 27.07.2018 13:36, schrieb Tim K:
Hello,
I'm creating a new app under Tomcat 9.0.8 (local dev: windows, live
servers: linux).
I have successfully created a custom JAAS authentication, which works
just
fine.
I have SSO enabled at the moment, but not sure if I really need it.
I left the def
Hello,
I'm creating a new app under Tomcat 9.0.8 (local dev: windows, live
servers: linux).
I have successfully created a custom JAAS authentication, which works just
fine.
I have SSO enabled at the moment, but not sure if I really need it.
I left the default StandardManager config in place, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gopi,
On 7/10/18 5:38 PM, Gopi Palla wrote:
> We have two dc, in one of the dc tomcat http sessions are exceeded.
> we are using introscope to monitor tomcat application server and
> getting the alerts, we kept the threshold value
Sorry, there was a typo on my last email.
On Wed, Jul 11, 2018, 3:08 AM Gopi Palla wrote:
> Hi,
>
> We have two dc, in one of the dc tomcat http sessions are exceeded. we are
> using introscope to monitor tomcat application server and getting the
> alerts, we kept the threshold
Gopi,
On Wed, Jul 11, 2018, 3:08 AM Gopi Palla wrote:
> Hi,
>
> We have two dc, in one of the dc tomcat http sessions are exceeded. we are
> using introscope to monitor tomcat application server and getting the
> alerts, we kept the threshold value as 850 in introscope
>
Do
os García
Asunto: Re: Sticky sessions not working at get_most_suitable_worker
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Carlos,
On 6/30/18 4:12 AM, Carlos García wrote:
> I' m working on a LB configuration with Apache/2.4.18 (Ubuntu)
> mod_jk/1.2.41 and not getting wanted resu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Carlos,
On 6/30/18 4:12 AM, Carlos García wrote:
> I' m working on a LB configuration with Apache/2.4.18 (Ubuntu)
> mod_jk/1.2.41 and not getting wanted results.
>
>
> My workers config is:
>
>
> worker.list=balanceFFG, jk-status # tomcat-pro-0
Hello.
I' m working on a LB configuration with Apache/2.4.18 (Ubuntu) mod_jk/1.2.41
and not getting wanted results.
My workers config is:
worker.list=balanceFFG, jk-status
# tomcat-pro-03 por COLT
worker.FFG1.host=tomcat-pro-03
worker.FFG1.port=8009
worker.FFG1.type=ajp13
worker.FFG1.stick
Am 23.03.2018 um 11:19 schrieb Martin Knoblauch:
Hi Rainer,
so basically I took the Apache path and ended up with the following brute
force method:
RewriteCond "%{REQUEST_METHOD}" "GET"
RewriteRule ^/xxx/facelets/logon.xhtml$ - [E=login_jsid:%{HTTP_COOKIE}]
CustomLog "/opt/xxx/apache2/logs/lo
connections being opened. This prevents us
>> from "idle down" Tomcats in a timely fashion. This hurts when a restart is
>> needed. While our empathy for human clients is pretty limited, we care a
>> lot about our automated workloads :-)
>>
>> Our setu
we care a lot about our
>>> automated workloads :-)
>>>
>>> Our setup: Apache 2.4.x frontend -> mod_jk(1.2.42) balancer,
>>> sticky sessions -> a bunch of Tomcat 7 (yes I know. Oldie but
>>> Goldie :-) workers.
>>>
>>> As far
Tomcats in a timely fashion. This
> hurts when a restart is needed. While our empathy for human clients
> is pretty limited, we care a lot about our automated workloads :-)
>
> Our setup: Apache 2.4.x frontend -> mod_jk(1.2.42) balancer,
> sticky sessions -> a bunch of Tomcat 7 (ye
ly fashion. This hurts when a
restart is
needed. While our empathy for human clients is pretty limited, we care a
lot about our automated workloads :-)
Our setup: Apache 2.4.x frontend -> mod_jk(1.2.42) balancer, sticky
sessions -> a bunch of Tomcat 7 (yes I know. Oldie but Goldie :-)
wor
While our empathy for human clients is pretty limited, we care a
lot about our automated workloads :-)
Our setup: Apache 2.4.x frontend -> mod_jk(1.2.42) balancer, sticky
sessions -> a bunch of Tomcat 7 (yes I know. Oldie but Goldie :-) workers.
As far as I understand, the problem ar
imited, we care a
lot about our automated workloads :-)
Our setup: Apache 2.4.x frontend -> mod_jk(1.2.42) balancer, sticky
sessions -> a bunch of Tomcat 7 (yes I know. Oldie but Goldie :-) workers.
As far as I understand, the problem arises with HTTP(S) clients that cache
the session cookies.
On 19/01/18 20:40, Christopher Schultz wrote:
> Mark,
>
> On 1/19/18 3:04 AM, Mark Thomas wrote:
>> On 18/01/18 20:11, Christopher Schultz wrote:
>>> Speaking of "expensive" objects, we do have a "user" object in
>>> the session. If the user isn't there, we throw all kinds of
>>> exceptions and do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 1/19/18 3:04 AM, Mark Thomas wrote:
> On 18/01/18 20:11, Christopher Schultz wrote:
>> Speaking of "expensive" objects, we do have a "user" object in
>> the session. If the user isn't there, we throw all kinds of
>> exceptions and don't let
On 18/01/18 20:11, Christopher Schultz wrote:
> Olaf,
>
> On 1/18/18 1:28 PM, Olaf Kock wrote:
>
>> On 18.01.2018 06:37, Christopher Schultz wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>>
>>> Mark,
>>>
>>> On 1/17/18 4:31 PM, Mark Thomas wrote:
On 17/01/18 17:05, Christopher
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Olaf,
On 1/18/18 1:28 PM, Olaf Kock wrote:
>
> On 18.01.2018 06:37, Christopher Schultz wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> Mark,
>>
>> On 1/17/18 4:31 PM, Mark Thomas wrote:
>>> On 17/01/18 17:05, Christopher Schultz
On 18.01.2018 06:37, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 1/17/18 4:31 PM, Mark Thomas wrote:
On 17/01/18 17:05, Christopher Schultz wrote:
All,
I have a use-case related to caching where I need to make sure
that an operation only happens one t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 1/17/18 4:31 PM, Mark Thomas wrote:
> On 17/01/18 17:05, Christopher Schultz wrote:
>> All,
>>
>> I have a use-case related to caching where I need to make sure
>> that an operation only happens one time with respect to an object
>> in the
On 17/01/18 17:05, Christopher Schultz wrote:
> All,
>
> I have a use-case related to caching where I need to make sure that an
> operation only happens one time with respect to an object in the
> session. Basically, I want to build a cache and put it into the
> session, but it needs to be thread-
2018-01-17 20:05 GMT+03:00 Christopher Schultz :
>
> All,
>
> I have a use-case related to caching where I need to make sure that an
> operation only happens one time with respect to an object in the
> session. Basically, I want to build a cache and put it into the
> session, but it needs to be thr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
I have a use-case related to caching where I need to make sure that an
operation only happens one time with respect to an object in the
session. Basically, I want to build a cache and put it into the
session, but it needs to be thread-safe enou
Hi Mark,
i have extended Shiro's default sid generator (JavaUuidSessionIdGenerator),
providing ids according to your suggestion, but unfortunately we obtain the
same behaviour.
After deploying the new app upgrade, users on the old release are logged out
again.
--
Sent from: http://tomcat.10.x6.
tomatically redirected to login page. Every request after the new
>release
>is treated as new session and redirected to the brand new release.
>
>I read here
><https://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Parallel_deployment>
>
>that Tomcat makes some d
ed to the brand new release.
I read here
<https://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Parallel_deployment>
that Tomcat makes some decision depending on sessions infos.
It seems that the transition to Shiro's native session management completely
blinds Tomcat, preven
On 29 September 2017 15:38:12 BST, "Singh, Rahul (CWM-NR)"
wrote:
>Hi,
>We are using Tomcat 7
>My question is - Why does Tomcat Session Replication require Sticky
>sessions to be enabled?
It doesn't.
>We cannot have a sticky session setup in our servers, due
Hi,
We are using Tomcat 7
My question is - Why does Tomcat Session Replication require Sticky sessions to
be enabled?
We cannot have a sticky session setup in our servers, due to policy issues. To
maintain session state across different machines, we were planning to use
session replication. But
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Anthony,
On 5/24/17 6:40 PM, Anthony, Clark R [US] (MS) wrote:
> Hello, I'm currently using Tomcat 8.5.14. I'd like to be able to
> limit the number of active sessions across the entire Tomcat
> server. I saw the "maxActi
Hello,
I'm currently using Tomcat 8.5.14. I'd like to be able to limit the number of
active sessions across the entire Tomcat server. I saw the "maxActiveSessions"
value in the Manager configuration component, but that appears to be required
to be nested inside a Context o
e a
> way to configure connector in such a way that no session is
> created.
The connectors don't create sessions, so this is unlikely to do with
the choice of connector. What happens if you try the APR or NIO2
connectors and repeat your tests?
> I have traffic of around 4 re
second. All the requests are state less. so each of them
create a session. After 10 minutes, the Tomcat stops taking any further
requests and when I viewed the heap dump, it says there is a concurrent map
which has many objects of sessions.
While using Tomcat 6.0.36,. no sessions were created
inutes
> >
> > Hi, Two of our servers reached max heap and we had to restart to
> > resolve the issue.
> >
> > In troubleshooting, we noticed Http Sessions had stopped expiring
> > 05/12th and reached 25K over a period of 11 days. I noticed the
> > same behav
ion: *7.0.40 *Session Timeout: *30 minutes
>
> Hi, Two of our servers reached max heap and we had to restart to
> resolve the issue.
>
> In troubleshooting, we noticed Http Sessions had stopped expiring
> 05/12th and reached 25K over a period of 11 days. I noticed the
> s
issue.
In troubleshooting, we noticed Http Sessions had stopped expiring 05/12th
and reached 25K over a period of 11 days. I noticed the same behavior in
both servers, the session expiration seem to have stopped on both of them
around the same time. I'm saying this because from looking a
1 - 100 of 1054 matches
Mail list logo
