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 PM
-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
/github.com/Netflix/Hystrix
>
> -Ravi
>
>
> 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
&
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/
-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
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 t
-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:
>>>
>
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 take
-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 20
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 somet
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:
J
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.
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.
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
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
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
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
with
> 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
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 gen
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 preserved
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:
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
M
on ID
>> and the worker name. I doubt two servers would generate the same hex
>> digits for the session. Therefore, your server must be working as
>> expected, you are just interpreting the logs incorrectly.
>>
>> -Original Message-
>> From: Roy McMorran [mailto
orran [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
: 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 ove
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 fa
27 matches
Mail list logo
