Re: Smooth applications migration in a J2EE cluster [mod_jk]

[Anthony Vromant]

Hi Rainer,

Thanks for this explanations. I'm going to try to give you more 
technical informations.


Rainer Jung wrote:

Hi,

yes I looked at the animation. Although I must confess, that I don't get
much out of it technically. What's the reason for the need to test
session validity? Is it needed to find out, if a node already got
upgraded to a new app version, so the session needs to get routed to a
node, still running the old app version? That's what I expect, since you
introduced worker "versions" (one could also name it "generation").

  
You're right, the animation doesn't show the technical part of prototype 
at all.


Here is the explanation about the session validity checking :

This test aims to have users with expired sessions and URL encoded 
bookmarks

(or long running browsers with cookies cached) redirected to a node
hosting the new version of the application.
If this test is not done during the update, these users will start a new 
session on a
node hosting the old version of application (and so, perhaps just before 
the stop of these node).

Do you agree with this ?

OK, we are only talking about cluster (in the sense of session
replication) and I assume, that we are interested in the case of an
application update, which is non-compatible concerning sessions and/or
URL structure.

  
Exactly. And beyond than sessions or URL structure, we can address the 
ejb  application update (stateful), the data models update (database), 
or even the update of the application server itself.

At the moment, sessions will be routed according to the routing suffix
in their id. Sessions which failed over can be rewritten (get another
routing suffix) by a Valve and thus be bound to another (surviving)
node. But sessions which have been idle will still be called with the
old suffix by the browser the next time they are used. If the node got
an update in the meantime, they will get routed to an incompatible node
and throw an error.

As a first simple workaround one could use two sets of workers and of
target (tomcat) nodes. One set would be stopped, on active at a time.
The two sets use different jvmRoutes. Replication is not done across set
boundaries.

  

When you say "2 sets of workers", you mean using the notion of domains ?

You upgrade the stopped set, test it via an internal connector/vhost and
then change its activation to active. Also you change the activation of
the formerly active set to disabled. New sessions will go to the updated
set, old sessions will still go to the unchanged set. Invalid sessions
will need to redirect to a start page without session information. After
some (depending on session use time) you stop the disabled set, to
prevent people with URL encoded bookmarks (or long running browsers with
cookies cached) to still reach the old version.

  

One of our objective is to use as much as possible mod_jk's capabilities.
So our prototype is based on using of these features :
- disabling a worker
- session rewriting (with a Valve)
- route modification

I've tried to pass the scenario you explain here, and i had a problem :

Here's my mod_jk (1.2.20) configuration :
worker1 : route = domain1.worker1, domain=domain1
worker2 : route = domain1.worker2, domain=domain1
worker3 : route = domain1.worker3, domain=domain1
Sticky session = true

And here's the test :
1/ Session initialization on worker1 : JSESSIONID.domain1.worker1
2/ Stop worker1
3/ Upgrade worker1
4/ Change route/domain of worker1 : route = domain2.worker1, domain=domain2
5/ At the same time : Active worker1 and disable worker 2 and 3
6/ Refresh on JSESSIONID.domain1.worker1
 -> The request still access on worker1

Whereas we want her to be routed to the
old version of application (so workers 2 or 3).
For the requests initialization on worker 2 or 3, it's ok.

Perhaps I missed something.

I'm actually writing some sequence diagrams to formalize all this uses
cases.
Do you have any ideas about that ?

Now this scenario does not really help, if you want to do *many*
updates. It granularity is somehow to coarse. To make it work more
smoothly, we would need an automatic way of managing jvmRoute,
worker.route and worker.domain consistently during application upgrade
(increasing generation counter which gets appended to the route). It
looks like you did something like that?

  

We have the same point of view on the granularity of a migration.
Actually, there's a lot of commands to make in an update, and a lot of
those may be transparent to the users.

Somehow I don't really see the need of checking the validity of a
session by mod_jk. We only need to know, which version of the app the
session belongs to, and which version of the app the various workers
talk to. This could be done by a generation counter in jvmRoute and all
routing related strings in mod_jk.

  

Yes, i understand that we could manage the link session/version with the
jvmRoute.
It's what we aim to do.

In your original mail, you talked about additional hooks you wo

DO NOT REPLY [Bug 41206] New: - Remote start of application fails

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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

   Summary: Remote start of application fails
   Product: Tomcat 6
   Version: unspecified
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: minor
  Priority: P5
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Running Tomcat 6.0.2 on Wondows2000 server
>From a web application we wish to control an application program running
under administrator on the server PC.
We first start a helper application program which runs CreateProcessWithLogonW
to start the main program.
This fails in the helper program with Window error 142.
However if 'Allow service to interact with desktop' is selected then it works.
On XP systems there is no problem.
The helper program runs correctly when started locally, either in a development
environment (DELPHI) or from dos.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41207] New: - wrong round-up

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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

   Summary: wrong round-up
   Product: Tomcat 5
   Version: Unknown
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Servlet & JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41208] New: - strange behaviour of fmt:formatNumber

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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

   Summary: strange behaviour of fmt:formatNumber
   Product: Tomcat 5
   Version: 5.5.0
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Servlet & JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


(I hope, I choose right component)
4.5:  (must be 
5)
5.5: 
3.5: 
6.5:  (must be 
7)

produces 
4.5: 4 (must be 5)
5.5: 6
3.5: 4
6.5: 6 (must be 7)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41207] - wrong round-up

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41208] - strange behaviour of fmt:formatNumber

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-12-19 03:37 ---
Not a tomcat bug - its an issue with the JSTL tag implementation of fmt. But it 
appears - its a known issue.


http://robobruin.blogspot.com/2006/07/fmtformatnumber-rounding-behavior.html

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ClientAbortException: java.net.SocketException: Connection reset

[??]

The real reason for the tomcat server stop accept request is the 
"java.lang.OutOfMemoryError: Java heap space"!

yuan hong


- Original Message - 
From: "aeonsun" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, December 19, 2006 10:57 AM
Subject: ClientAbortException: java.net.SocketException: Connection reset


> hello all:
> I'm useing tomcat5.5.17 .tomcat server catch the follow exception and it
> don't work sometimes (the http port has be listing yet and no any  message
> if I connected it. The pertinent code is after the exception.)
> 
> ClientAbortException:  java.net.SocketException: Connection reset
>at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java
> :327)
>at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:293)
>at org.apache.catalina.connector.CoyoteOutputStream.flush(
> CoyoteOutputStream.java:97)
>at javax.imageio.stream.FileCacheImageOutputStream.flushBefore(
> FileCacheImageOutputStream.java:214)
>at javax.imageio.stream.ImageInputStreamImpl.flush (
> ImageInputStreamImpl.java:801)
>at com.sun.imageio.plugins.jpeg.JPEGImageWriter.write(
> JPEGImageWriter.java:1002)
>at javax.imageio.ImageWriter.write(ImageWriter.java:598)
>at javax.imageio.ImageIO.write (ImageIO.java:1450)
>at javax.imageio.ImageIO.write(ImageIO.java:1524)
>at net.m2.webapp.action.RandomImageServlet.doGet(RandomImageServlet.java
> :45)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java :689)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:252)
>at org.apache.catalina.core.ApplicationFilterChain.doFilter (
> ApplicationFilterChain.java:173)
>at net.m2.util.EncodingFilter.doFilter(EncodingFilter.java:54)
>at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
> ApplicationFilterChain.java:202)
>at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:173)
>at org.apache.catalina.core.StandardWrapperValve.invoke(
> StandardWrapperValve.java:213)
>at org.apache.catalina.core.StandardContextValve.invoke (
> StandardContextValve.java:178)
>at org.apache.catalina.core.StandardHostValve.invoke(
> StandardHostValve.java:126)
>at org.apache.catalina.valves.ErrorReportValve.invoke(
> ErrorReportValve.java:105)
>at org.apache.catalina.core.StandardEngineValve.invoke (
> StandardEngineValve.java:107)
>at org.apache.catalina.connector.CoyoteAdapter.service(
> CoyoteAdapter.java:148)
>at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
> :869)
>at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(
> Http11BaseProtocol.java:664)
>at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(
> PoolTcpEndpoint.java:527)
>at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(
> LeaderFollowerWorkerThread.java :80)
>at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
> ThreadPool.java:684)
>at java.lang.Thread.run(Thread.java:595)
> Caused by: java.net.SocketException: Connection reset
>at java.net.SocketOutputStream.socketWrite (SocketOutputStream.java:96)
>at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
>at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(
> InternalOutputBuffer.java:746)
>at org.apache.tomcat.util.buf.ByteChunk.flushBuffer (ByteChunk.java:433)
>at org.apache.coyote.http11.InternalOutputBuffer.flush(
> InternalOutputBuffer.java:304)
>at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java
> :991)
>at org.apache.coyote.Response.action (Response.java:182)
>at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java
> :322)
>... 28 more
> ERROR [http-80-Processor108] (ThreadPool.java:693) - Caught exception (
> java.lang.OutOfMemoryError : Java heap space) executing
> [EMAIL PROTECTED], terminating
> thread
> ERROR [http-80-Processor36] (CoyoteAdapter.java:157) - An exception or error
> occurred in the container during the request processing
> java.lang.OutOfMemoryError: Java heap space
> ERROR [http-80-Processor58] (FrameworkServlet.java:413) - Could not complete
> request
> org.springframework.web.util.NestedServletException: Handler processing
> failed; nested exception is java.lang.OutOfMemoryError: Java heap space
> java.lang.OutOfMemoryError: Java heap space
> ERROR [http-80-Processor83] (FrameworkServlet.java:413) - Could not complete
> request
> org.springframework.web.util.NestedServletException : Handler processing
> failed; nested exception is java.lang.OutOfMemoryError: Java heap space
> java.lang.OutOfMemoryError: Java heap space
> ERROR [http-80-Processor88] (FrameworkServlet.java:413) - Could not complete
> request
> org.springframework.web.util.NestedServletException: Handler processing
> failed; nested exception is

DO NOT REPLY [Bug 41206] - Remote start of application fails

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-12-19 04:03 ---
As far as I can tell this is as a result of how Windows 2000 manages security
for services. There isn't anything Tomcat can do about this.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41213] New: - URLs with session ID in them no longer work

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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

   Summary: URLs with session ID in them no longer work
   Product: Tomcat 5
   Version: 5.5.20
  Platform: Other
   URL: https://bowmore.cs.st-
andrews.ac.uk/finesse/Resources.do;jsessionid=AA
AA
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I have a web application which users first access through a static login page.
They then enter a username and password, and are redirected to a servlet, which
creates a session, sets whether they have authenticated successfully in that
session, and redirects them on to the next page:

response.sendRedirect(response.encodeRedirectURL(url));

This worked fine in Tomcat versions up to 5.5.17, however having just installed
5.5.20 on our development server, I now get a 404 error instead of the page.
Removing the ";jsessionid=..." from the URL does work correctly (giving either a
403 if the user is not logged in, or has cookies disabled, or the correct page
if they're logged in and have cookies for the session system to use instead):

https://bowmore.cs.st-andrews.ac.uk/finesse/Resources.do

At a guess, looking at the change log, "Improve handling of the ';' character in
the URL so that it is now allowed if properly %xx encoded. (remm)" is somehow
related, but that's just a guess.

Tested using JDK 1.5_10, from Firefox 3.0 Alpha 1, Safari 2.0.4 and Lynx 2.8.5.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Smooth applications migration in a J2EE cluster [mod_jk]

[Anthony Vromant]

Hi,

The scenario you explained me doesn't work in my env. I'm trying to find 
out the reasons below :


Here is the code :

jk_lb_worker.c : "find_bysession_route()"

candidate = find_by_session(p, name, l);

  if (!candidate) {
  uses_domain = 1;
  candidate = find_best_bydomain(p, name, l);
  }

If route was changed on a worker, "find_by_session()" method can't find 
a good worker (and thus its domain).


It seems to me strange in this case, to call "find_best_bydomain()" 
method with a route in parameter whereas a domain name is expected  ?


With the current code, when a route is modified (!candidate), domain 
affinity doesn't work anymore for the old active session related to the 
changed worker ?

Is it a normal behavior according to you ?

The JSESSIONID only knows the route, but not the domain and the code 
have to cope with this miss.
By the way, I've also tried to use routes with a period like 
'domain.worker', but it changes nothing.


Regards,
Anthony

Anthony Vromant wrote:

Hi Rainer,

Thanks for this explanations. I'm going to try to give you more 
technical informations.


Rainer Jung wrote:

Hi,

yes I looked at the animation. Although I must confess, that I don't get
much out of it technically. What's the reason for the need to test
session validity? Is it needed to find out, if a node already got
upgraded to a new app version, so the session needs to get routed to a
node, still running the old app version? That's what I expect, since you
introduced worker "versions" (one could also name it "generation").

  
You're right, the animation doesn't show the technical part of 
prototype at all.


Here is the explanation about the session validity checking :

This test aims to have users with expired sessions and URL encoded 
bookmarks

(or long running browsers with cookies cached) redirected to a node
hosting the new version of the application.
If this test is not done during the update, these users will start a 
new session on a
node hosting the old version of application (and so, perhaps just 
before the stop of these node).

Do you agree with this ?

OK, we are only talking about cluster (in the sense of session
replication) and I assume, that we are interested in the case of an
application update, which is non-compatible concerning sessions and/or
URL structure.

  
Exactly. And beyond than sessions or URL structure, we can address the 
ejb  application update (stateful), the data models update (database), 
or even the update of the application server itself.

At the moment, sessions will be routed according to the routing suffix
in their id. Sessions which failed over can be rewritten (get another
routing suffix) by a Valve and thus be bound to another (surviving)
node. But sessions which have been idle will still be called with the
old suffix by the browser the next time they are used. If the node got
an update in the meantime, they will get routed to an incompatible node
and throw an error.

As a first simple workaround one could use two sets of workers and of
target (tomcat) nodes. One set would be stopped, on active at a time.
The two sets use different jvmRoutes. Replication is not done across set
boundaries.

  

When you say "2 sets of workers", you mean using the notion of domains ?

You upgrade the stopped set, test it via an internal connector/vhost and
then change its activation to active. Also you change the activation of
the formerly active set to disabled. New sessions will go to the updated
set, old sessions will still go to the unchanged set. Invalid sessions
will need to redirect to a start page without session information. After
some (depending on session use time) you stop the disabled set, to
prevent people with URL encoded bookmarks (or long running browsers with
cookies cached) to still reach the old version.

  

One of our objective is to use as much as possible mod_jk's capabilities.
So our prototype is based on using of these features :
- disabling a worker
- session rewriting (with a Valve)
- route modification

I've tried to pass the scenario you explain here, and i had a problem :

Here's my mod_jk (1.2.20) configuration :
worker1 : route = domain1.worker1, domain=domain1
worker2 : route = domain1.worker2, domain=domain1
worker3 : route = domain1.worker3, domain=domain1
Sticky session = true

And here's the test :
1/ Session initialization on worker1 : JSESSIONID.domain1.worker1
2/ Stop worker1
3/ Upgrade worker1
4/ Change route/domain of worker1 : route = domain2.worker1, 
domain=domain2

5/ At the same time : Active worker1 and disable worker 2 and 3
6/ Refresh on JSESSIONID.domain1.worker1
 -> The request still access on worker1

Whereas we want her to be routed to the
old version of application (so workers 2 or 3).
For the requests initialization on worker 2 or 3, it's ok.

Perhaps I missed something.

I'm actually writing some sequence diagrams to formalize all this uses
cases.
Do you have any ideas about that ?

Now this scenario does not real

Re: Smooth applications migration in a J2EE cluster [mod_jk]

[Rainer Jung]

Hi Anthony,

Anthony Vromant schrieb:
> Here is the explanation about the session validity checking :
> 
> This test aims to have users with expired sessions and URL encoded
> bookmarks
> (or long running browsers with cookies cached) redirected to a node
> hosting the new version of the application.
> If this test is not done during the update, these users will start a new
> session on a
> node hosting the old version of application (and so, perhaps just before
> the stop of these node).
> Do you agree with this ?

Ah OK, yes I agree. You could use a filter (or Valve) to redirect
requests with an invalid session to the login page without URL encoding
and invalidating the cookie. That way you would destroy the invalid
binding to this node.

If we would try to do that with mod_jk directly, mod_jk would need to
have a shadow copy of the session list, something which doesn't sound
right. OK, mod_jk could ask tomcat about the session, but we can also
simply forward and let the node delete the binding.

>> As a first simple workaround one could use two sets of workers and of
>> target (tomcat) nodes. One set would be stopped, on active at a time.
>> The two sets use different jvmRoutes. Replication is not done across set
>> boundaries.
>>
> When you say "2 sets of workers", you mean using the notion of domains ?

With sets I simply mean sets :) Somehow you configure each worker twice,
but with different names. Domains come into play, to define failover
rules between the workers. Failover should not hapen between the sets.
So each set will belong to one domain. A mod_jk domain is nothing else,
than failover information (try another worker in the same domain first,
before trying any other worker).

>> You upgrade the stopped set, test it via an internal connector/vhost and
>> then change its activation to active. Also you change the activation of
>> the formerly active set to disabled. New sessions will go to the updated
>> set, old sessions will still go to the unchanged set. Invalid sessions
>> will need to redirect to a start page without session information. After
>> some (depending on session use time) you stop the disabled set, to
>> prevent people with URL encoded bookmarks (or long running browsers with
>> cookies cached) to still reach the old version.
>>
>>   
> One of our objective is to use as much as possible mod_jk's capabilities.
> So our prototype is based on using of these features :
> - disabling a worker
> - session rewriting (with a Valve)
> - route modification
> 
> I've tried to pass the scenario you explain here, and i had a problem :
> 
> Here's my mod_jk (1.2.20) configuration :
> worker1 : route = domain1.worker1, domain=domain1
> worker2 : route = domain1.worker2, domain=domain1
> worker3 : route = domain1.worker3, domain=domain1
> Sticky session = true
> 
> And here's the test :
> 1/ Session initialization on worker1 : JSESSIONID.domain1.worker1
> 2/ Stop worker1
> 3/ Upgrade worker1
> 4/ Change route/domain of worker1 : route = domain2.worker1, domain=domain2
> 5/ At the same time : Active worker1 and disable worker 2 and 3
> 6/ Refresh on JSESSIONID.domain1.worker1
>  -> The request still access on worker1
> 
> Whereas we want her to be routed to the
> old version of application (so workers 2 or 3).
> For the requests initialization on worker 2 or 3, it's ok.
> 
> Perhaps I missed something.

Active:
worker1a : route = worker1a, domain=domain1
worker2a : route = worker2a, domain=domain1
worker3a : route = worker3a, domain=domain1
Stopped:
worker1b : route = worker1b, domain=domain2
worker2b : route = worker2b, domain=domain2
worker3b : route = worker3b, domain=domain2
Sticky session = true

Then you would follow the above steps.

Regards,

Rainer

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Smooth applications migration in a J2EE cluster [mod_jk]

[Rainer Jung]

Anthony Vromant schrieb:
> Hi,
> 
> The scenario you explained me doesn't work in my env. I'm trying to find
> out the reasons below :
> 
> Here is the code :
> 
> jk_lb_worker.c : "find_bysession_route()"
> 
> candidate = find_by_session(p, name, l);
> 
>   if (!candidate) {
>   uses_domain = 1;
>   candidate = find_best_bydomain(p, name, l);
>   }
> 
> If route was changed on a worker, "find_by_session()" method can't find
> a good worker (and thus its domain).

It's not necessary to find a "good" worker (whatever that would mean).
find_by_session() only checks for a worker with the right name. So the
question is: why did you change the route? If you changed the route,
because the session was invalid, we proceed with a request without
session id and it can be balanced to any "active" node. In all other
cases we don't want to change the route. Then the function finds the
worker as a candidate and the code will bypass the "if" above. The next
part of the code checks, if the candidate does work (is usable). If not,
it will use the redirect or domain attributes to find an alternative.

> 
> It seems to me strange in this case, to call "find_best_bydomain()"
> method with a route in parameter whereas a domain name is expected  ?

This part of the code does not fit into our discussion. It can be used
for stateless service swithout stickyness. You can have the same
jvmRoute on a set of nodes and then have different workers, each with
domain=jvmRoute. This is not necessary any more, because we now can
define "route" of a worker. This feature did not exist, when the above
code was written.

> 
> With the current code, when a route is modified (!candidate), domain
> affinity doesn't work anymore for the old active session related to the
> changed worker ?
> Is it a normal behavior according to you ?

Why do you want to modify the route?

> 
> The JSESSIONID only knows the route, but not the domain and the code
> have to cope with this miss.
> By the way, I've also tried to use routes with a period like
> 'domain.worker', but it changes nothing.

Regards,

Rainer

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 40909] - High CPU Usage When Using mod_jk or mod_proxy_ajp connectors

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Windows Server 2003 |Windows 2000




--- Additional Comments From [EMAIL PROTECTED]  2006-12-19 15:37 ---
I've just ran into the same, or at least similar, problem using the following 
config:
IIS 5
Tomcat 5.5.20 + tcnative-1.dll 1.1.8
mod_jk/isapi-redirect 1.2.19
JDK 1.5
Windows 2000 server

When I start Tomcat only (so no IIS), everything works fine. As soon as I start 
IIS, the CPU load pops to 100%. The task consuming the CPU is "tomcat5.exe".

I've also tried using tcnative.dll 1.1.7, but it resulted in the same 
behaviour. When I tried WITHOUT tcnative.dll, everything worked fine.

So whatever is it, it is NOT fixed in tcnative 1.1.6.

Until just now, I was using Tomcat 5.5.15, isapi redirector 1.2.15 and tcnative-
1.dll 1.1.0: this combination worked fine!

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ClientAbortException: java.net.SocketException: Connection reset

[aeonsun]

of course, this is the reason  for tomcat doesn't work,but what brought tomcat 
to stop work? it's ClientAbortException: java.net.SocketException: Connection 
reset.Tomcat server has down by this exception and no more any log later.

- Original Message - 
From: "??" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" 
Sent: Tuesday, December 19, 2006 7:43 PM
Subject: Re: ClientAbortException: java.net.SocketException: Connection reset


> The real reason for the tomcat server stop accept request is the 
> "java.lang.OutOfMemoryError: Java heap space"!
> 
> yuan hong
> 
> 
> - Original Message - 
> From: "aeonsun" <[EMAIL PROTECTED]>
> To: 
> Sent: Tuesday, December 19, 2006 10:57 AM
> Subject: ClientAbortException: java.net.SocketException: Connection reset
> 

mod_jk, default value of retries is still 3?

[Takayuki Kaneko]

Hi,

I found a mismatch between the document and source code about the
default value of retries.

It's my understanding that the default value was changed from 3 to 2 at r420266.
http://svn.apache.org/viewvc?view=rev&revision=420266

But the latest doument says it is still 3.
http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/jk-1.2.20/docs/reference/workers.html

Thanks.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]