From: Ja kub [jjaku...@gmail.com]
Sent: Thursday, June 13, 2013 1:11 AM
To: Tomcat Users List
Subject: Re: http request (no only session) replication in cluster
Christopher
Thx for response, I will inform guys from business about what You have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jakub,
On 6/18/13 3:27 AM, Ja kub wrote:
Ravindra,
Thx for idea, I will read about it, but at first glance it looks
like with 5000 pending servlet requests I will have 5000 threads
awaiting response from cxf client, with async servlet and
yes, most of time is waiting,
I use tomcat NIO connector, with async cxf webservice server (exposed as
async servlet) and async cxf client,
I use no my own threaded-queue
regards
Jakub
ps
possibly camel could do it more elegantly and with less programming effort
On Tue, Jun 18, 2013 at 5:21
From: Ja kub [jjaku...@gmail.com]
Sent: Thursday, June 13, 2013 1:11 AM
To: Tomcat Users List
Subject: Re: http request (no only session) replication in cluster
Christopher
Thx for response, I will inform guys from business about what You have
written, and let them consider it
Regards
Jakub
On Wed
Christopher
Thx for response, I will inform guys from business about what You have
written, and let them consider it
Regards
Jakub
On Wed, Jun 12, 2013 at 4:10 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jakob,
On 6/11/13
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jakob,
On 6/11/13 5:04 PM, Ja kub wrote:
requirement is system should be possible to process 160 req/sec
(200 is better to multiply) and system is kind of failover proxy
itself
there are 2 backing webservices, each can answer max 20s, it
What can be done to guarantee failover in below scenario:
2 tomcats behind cisco loadbalancer
1 http request can last very long about 50 seconds - response from
webservice can take so long
load is 200 requests per second
I must response in max 4 seconds more than backing webservice
is there
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ja,
On 6/11/13 9:54 AM, Ja kub wrote:
What can be done to guarantee failover in below scenario:
2 tomcats behind cisco loadbalancer 1 http request can last very
long about 50 seconds - response from webservice can take so long
load is 200
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ja,
On 6/11/13 9:54 AM, Ja kub wrote:
What can be done to guarantee failover in below scenario:
2 tomcats behind cisco loadbalancer 1 http request can last very
long about 50 seconds - response from webservice can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
André,
On 6/11/13 11:32 AM, André Warnier wrote:
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256
Ja,
On 6/11/13 9:54 AM, Ja kub wrote:
What can be done to guarantee failover in below scenario:
2 tomcats behind
Andre, Christopher
thx for response,
requirement is system should be possible to process 160 req/sec (200 is
better to multiply)
and system is kind of failover proxy itself
there are 2 backing webservices, each can answer max 20s, it there is
timeout on first, I must call the second, if there is
what you're seeing is correct.
the server did fail over, and by changing the session id, it ensures
that it does not do fail back
Filip
Roy McMorran wrote:
Hello all,
I've built a very simple 2-member Tomcat cluster for testing, but I am
unable to get the session replication quite right.
To stick with the analogy:
Your session's baby part is: FEBA6A8127A69079C79B7A641158CE20 and
that remains the same if with daddy or mommy.
Your session's daddy part is: itchy
and
Your session's mommy part is: scratchy
Enjoy them :)
János
On Apr 3, 2009, at 5:32 PM, Roy McMorran wrote:
[mailto:mcmor...@mdibl.org]
Sent: Thursday, April 02, 2009 10:59 AM
To: Tomcat Users List
Subject: Session Replication in Cluster
Hello all,
I've built a very simple 2-member Tomcat cluster for testing, but I am
unable to get the session replication quite right. The problem is when
I fail one
be working as
expected, you are just interpreting the logs incorrectly.
-Original Message-
From: Roy McMorran [mailto:mcmor...@mdibl.org] Sent: Thursday, April
02, 2009 10:59 AM
To: Tomcat Users List
Subject: Session Replication in Cluster
Hello all,
I've built a very simple 2
Mark Thomas wrote:
Nope. The job of that valve is to change the route - exactly what you
are seeing.
Thanks Mark,
Is it the expected behavior then, that the 2nd part of the session ID
changes after a failover, and a new cookie is set?
Thanks,
Roy
--
Roy McMorran
Systems Administrator
Roy McMorran wrote:
Mark Thomas wrote:
Nope. The job of that valve is to change the route - exactly what you
are seeing.
Thanks Mark,
Is it the expected behavior then, that the 2nd part of the session ID
changes after a failover, and a new cookie is set?
Yes
Mark
Mark Thomas wrote:
Roy McMorran wrote:
Thanks Mark,
Is it the expected behavior then, that the 2nd part of the session ID
changes after a failover, and a new cookie is set?
Yes
Mark
Interesting. I am certain I saw the other behavior (both parts of the
session ID were
Mark Thomas wrote:
Roy McMorran wrote:
Is it the expected behavior then, that the 2nd part of the session ID
changes after a failover, and a new cookie is set?
Yes
OK, please bear with me here, I may be just showing my ignorance with
respect to Tomcat and web applications in
From: Roy McMorran [mailto:mcmor...@mdibl.org]
Subject: Re: Session Replication in Cluster
If the session ID changes from ABC123.node1 to ABC123.node2, then
you will start a new session at the browser.
No, you get a new *cookie* at the browser; the session is something only the
server has
On Apr 3, 2009, at 3:31 PM, Roy McMorran wrote:
Mark Thomas wrote:
Roy McMorran wrote:
Is it the expected behavior then, that the 2nd part of the session
ID
changes after a failover, and a new cookie is set?
Yes
OK, please bear with me here, I may be just showing my ignorance
Caldarale, Charles R wrote:
From: Roy McMorran [mailto:mcmor...@mdibl.org]
Subject: Re: Session Replication in Cluster
If the session ID changes from ABC123.node1 to ABC123.node2, then
you will start a new session at the browser.
No, you get a new *cookie* at the browser; the session
János Löbb wrote:
If You look the values created by the session earlier with
...node1, than You will see the same values after fail over with
...node2. A new session would not know about them.
To verify it You can use the supplied SessionExmaple webapp.
It is like passing a baby among
János Löbb wrote:
If You look the values created by the session earlier with
...node1, than You will see the same values after fail over with
...node2. A new session would not know about them.
To verify it You can use the supplied SessionExmaple webapp.
OK, trying that.
So, using an
Roy McMorran wrote:
János Löbb wrote:
If You look the values created by the session earlier with
...node1, than You will see the same values after fail over with
...node2. A new session would not know about them.
To verify it You can use the supplied SessionExmaple webapp.
OK, trying
Hello all,
I've built a very simple 2-member Tomcat cluster for testing, but I am
unable to get the session replication quite right. The problem is when
I fail one member of the cluster. The behavior I was expecting is that
the other cluster member would take over the session ids for the
: Session Replication in Cluster
Hello all,
I've built a very simple 2-member Tomcat cluster for testing, but I am
unable to get the session replication quite right. The problem is when
I fail one member of the cluster. The behavior I was expecting is that
the other cluster member would take over
27 matches
Mail list logo
