You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Anthony Vromant <an...@bull.net> on 2006/12/05 16:46:45 UTC
Smooth applications migration in a J2EE cluster [mod_jk]
Hello,
I am member of the JOnAS team (http://jonas.objectweb.org/), the
ObjectWeb application server (http://www.objectweb.org/).
We are developing a prototype which provides a smooth web applications
migration mechanism within a Java EE cluster (without interruption of
service and in a transparent way for the clients, i.e. without loss of
sessions).
The system of distribution of the client's requests towards the adequate
version is actually based on a hook in mod_jk. During the update and
when a new version of the application is deployed, the clients having
started a session before the update are routed towards the cluster
hosting the old version, whereas the new clients (news sessions) are
routed towards the cluster hosting the new version of the application.
This prototype contains an administration API who provides
functionalities to manage the update (jkupdater : begin update, end
update, changed application version on a worker). The interface
jkmanager has also been adapted in order to add information related to
the migration.
We would be very interested to be able to exchange with you on this subject.
Feel free to give us your feedbacks. If you are interested, we can
provide further informations and source code.
Would it be possible to integrate such a feature in the original mod_jk
? If yes, we may contribute to the development by providing our code.
----------------------------------------------------------------
Anthony Vromant
http://jonas.objectweb.org
Bull, Architect of an Open World TM
http://www.bull.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Rainer Jung <ra...@kippdata.de>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Anthony Vromant <an...@bull.net>.
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 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 would need
>> inside mod_jk. What would that be?
>>
>>
> The hook was made in the first version of the prototype (mod_jk
> 1.2.15). We're now changing a lot of things..
>> Regards,
>>
>> Rainer
>>
> Regards,
> Anthony
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Anthony Vromant <an...@bull.net>.
Hi Rainer,
As we discussed recently, using a Tomcat Valve or a Filter to detect
invalidated session could be a good approach.
Can I have your feeling about such a Tomcat filter :
If session is invalid (or new)
- Set sendRedirect attribute of HtppResponse at the same value of
current HttpRequest path
- Invalidating the cookie
- Send Response
This filter would have to be active on disabled workers.
So when the request is (re)send by browser, mod_jk doesn't detect any
session informations and route the request to an active worker (so new
application version).
In this way, it will be transparent for the users.
Best wishes,
Anthony
Source code exemple :
if (started && session.isNew()) {
// invalidating the jsessionid cookie
// set a new session cookie
Cookie newCookie = new Cookie("JSESSIONID", "");
newCookie.setMaxAge(0);
String contextPath = ((HttpServletRequest) request)
.getContextPath();
if ((contextPath != null) && (contextPath.length() > 0)) {
newCookie.setPath(contextPath);
} else {
newCookie.setPath("/");
}
if (request.isSecure()) {
newCookie.setSecure(true);
}
((HttpServletResponse) response).addCookie(newCookie);
// set sendRedirect response
((HttpServletResponse) response)
.sendRedirect(((HttpServletRequest) request)
.getContextPath()
+ ((HttpServletRequest)
request).getServletPath());
return;
}
Rainer Jung wrote:
> 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.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Anthony Vromant <an...@bull.net>.
Hi Rainer,
I wanted to know if you had had time to think on the subject of the
invalidated session Valve ?
Other informations that you gave us before were very useful.
Thanks a lot.
Regards,
Anthony
Anthony Vromant wrote:
> Hi Rainer,
>
> In my test case, i start only with 3 actives workers.
> So i think you want me to make a graceful restart of apache in order
> to add the 3 stopped workers ?
> Is this that ?
> Anyhow, i understand that without changing route, this can be a good
> solution.
>
> But about the invalidated session Valve :
>
> If this Valve invalidates a cookie and redirects users to a login
> page, it is not transparent for the users.
>
> Can we imagine that during an update, if this Valve is activated and
> used, mod_jk detects it (through the response sent by the valve) and
> sends the request to an active worker ?
> It would be a kind of transparent fail-over implemented by mod_jk.
>
> Regards,
> Anthony
>
> Rainer Jung wrote:
>> 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: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Anthony Vromant <an...@bull.net>.
Hi Rainer,
In my test case, i start only with 3 actives workers.
So i think you want me to make a graceful restart of apache in order to
add the 3 stopped workers ?
Is this that ?
Anyhow, i understand that without changing route, this can be a good
solution.
But about the invalidated session Valve :
If this Valve invalidates a cookie and redirects users to a login page,
it is not transparent for the users.
Can we imagine that during an update, if this Valve is activated and
used, mod_jk detects it (through the response sent by the valve) and
sends the request to an active worker ?
It would be a kind of transparent fail-over implemented by mod_jk.
Regards,
Anthony
Rainer Jung wrote:
> 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: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Rainer Jung <ra...@kippdata.de>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Anthony Vromant <an...@bull.net>.
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 would need
> inside mod_jk. What would that be?
>
>
The hook was made in the first version of the prototype (mod_jk 1.2.15).
We're now changing a lot of things..
> Regards,
>
> Rainer
>
Regards,
Anthony
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Rainer Jung <ra...@kippdata.de>.
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").
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.
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.
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.
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?
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.
In your original mail, you talked about additional hooks you would need
inside mod_jk. What would that be?
Regards,
Rainer
Anthony Vromant schrieb:
> Hi all,
>
> I would like to know if you had time to look at the demonstration of our
> prototype.
>
> We are very interested to get your feelings about that.
>
> Do you have ideas about our problem of testing the validity of a user
> session within mod_jk ?
> We're thinking about a mechanism relying on the JMX-Adaptor of Tomcat
> that mod_jk can
> invoke through the AJP interface. What's your opinion ?
>
> Thanks.
> Regards
>
> Anthony Vromant
>
> Anthony Vromant wrote:
>> Hi Rainer,
>>
>> First of all, thank you for these informations.
>>
>> Here is the HTTP link for the Flash demonstration of our prototype :
>> https://wiki.objectweb.org/jonas/Wiki.jsp?page=JOnASClusteringSmoothUpdateWebCluster
>>
>>
>> I am looking at the new features provided by mod_jk 1.2.20, the
>> dynamic configuration reloading is quite interesting.
>> We are going to bring our prototype to this new version.
>>
>> In our prototype, when a new request is coming with a JSESSIONID
>> cookie, a request is sent to the worker (tomcat) for checking the
>> validity (we need to know whether the session is still alive).
>> Currently, the HTTP protocol is used for invoking tomcat rather than
>> AJP. The control at the tomcat side is done through an internal
>> servlet which accesses the MBean manager for getting the current
>> sessions list.
>>
>> Do you have any suggestion for improving that ?
>>
>> Regards,
>> Anthony
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Anthony Vromant <an...@bull.net>.
Hi all,
I would like to know if you had time to look at the demonstration of our
prototype.
We are very interested to get your feelings about that.
Do you have ideas about our problem of testing the validity of a user
session within mod_jk ?
We're thinking about a mechanism relying on the JMX-Adaptor of Tomcat
that mod_jk can
invoke through the AJP interface. What's your opinion ?
Thanks.
Regards
Anthony Vromant
Anthony Vromant wrote:
> Hi Rainer,
>
> First of all, thank you for these informations.
>
> Here is the HTTP link for the Flash demonstration of our prototype :
> https://wiki.objectweb.org/jonas/Wiki.jsp?page=JOnASClusteringSmoothUpdateWebCluster
>
>
> I am looking at the new features provided by mod_jk 1.2.20, the
> dynamic configuration reloading is quite interesting.
> We are going to bring our prototype to this new version.
>
> In our prototype, when a new request is coming with a JSESSIONID
> cookie, a request is sent to the worker (tomcat) for checking the
> validity (we need to know whether the session is still alive).
> Currently, the HTTP protocol is used for invoking tomcat rather than
> AJP. The control at the tomcat side is done through an internal
> servlet which accesses the MBean manager for getting the current
> sessions list.
>
> Do you have any suggestion for improving that ?
>
> Regards,
> Anthony
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Anthony Vromant <an...@bull.net>.
Hi,
This will be better with this link :
https://wiki.objectweb.org/jonas/Wiki.jsp?page=JOnASClusteringSmoothUpdateWebCluster
You just have to click on "Launch the demonstration".
Sorry for the mistake.
Regards,
Anthony
Henri Gomez wrote:
> The page is password protected ;(
>
> Sad since I'm also very interested in seeing what you plain to do.
>
> Regards
>
> 2006/12/8, Anthony Vromant <an...@bull.net>:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Henri Gomez <he...@gmail.com>.
The page is password protected ;(
Sad since I'm also very interested in seeing what you plain to do.
Regards
2006/12/8, Anthony Vromant <an...@bull.net>:
> Hi Rainer,
>
> First of all, thank you for these informations.
>
> Here is the HTTP link for the Flash demonstration of our prototype :
> https://wiki.objectweb.org/jonas/Upload.jsp?page=JOnASClusteringSmoothUpdateWebCluster
>
>
> I am looking at the new features provided by mod_jk 1.2.20, the dynamic
> configuration reloading is quite interesting.
> We are going to bring our prototype to this new version.
>
> In our prototype, when a new request is coming with a JSESSIONID cookie,
> a request is sent to the worker (tomcat) for checking the validity (we
> need to know whether the session is still alive).
> Currently, the HTTP protocol is used for invoking tomcat rather than
> AJP. The control at the tomcat side is done through an internal servlet
> which accesses the MBean manager for getting the current sessions list.
>
> Do you have any suggestion for improving that ?
>
> Regards,
> Anthony
>
> Rainer Jung wrote:
> > Hi Anthony,
> >
> > since your oce is based on 1.2.15 first the information for you, that
> > between 1.2.15 and the released 1.2.19 there were a lot of features
> > added. No old features has been dropped, so it should be feature
> > compatible with 1.2.15. You can look at the changelog
> >
> > http://tomcat.apache.org/connectors-doc/changelog.html
> >
> > and maybe the easiest way is to scan the document
> >
> > http://tomcat.apache.org/connectors-doc/config/workers.html
> >
> > and for Apache
> >
> > http://tomcat.apache.org/connectors-doc/config/apache.html
> >
> > resp. for IIS
> >
> > http://tomcat.apache.org/connectors-doc/config/iis.html
> >
> > about new parameters, which you didn't know before. There are also
> > hints in the docs, which of the params have been added in which version.
> >
> > Concerning 1.2.20 I'll make a tarball for testing including the docs
> > most likely tonight. We changed a bit more, than was planned, so we
> > give people a couple of days to report problems early, before we tag
> > the release. Again, all changes will be contained in the configuration
> > reference guide.
> >
> > Regards,
> >
> > Rainer
> >
> > Anthony Vromant wrote:
> >> Rainer Jung wrote:
> >>> Mladen Turk wrote:
> >>>> Anthony Vromant wrote:
> >>>>>
> >>>>> Would it be possible to integrate such a feature in the original
> >>>>> mod_jk ? If yes, we may contribute to the development by providing
> >>>>> our code.
> >>>>>
> >>>>
> >>>> There is no need to ask something like that.
> >>>> Just like for any other patch bring in the code,
> >>>> and we'll discuss, but it cannot be answered in advance.
> >>>> Anyhow, according to the description it looks very interesting.
> >>>>
> >>>> Regards,
> >>>> Mladen.
> >>>
> >>> Exactly the same from me. The upcoming release 1.2.20 will already
> >>> include a lot of improvements in the jk status worker and we all
> >>> think, that managing changes in a distributed 24x7 system already is
> >>> a very important topic.
> >>>
> >>> Waiting for your proposals :)
> >>>
> >>> Rainer
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>
> >>>
> >> Glad to note that you are interested in this topic.
> >>
> >> I propose to send you as soon as possible a HTTP link towards a Flash
> >> presentation of our prototype.
> >> Thus you'll have a good overview of the feature.
> >>
> >> For the source code, we have to do some 'cleaning' work before being
> >> able to submit it to you.
> >>
> >> Can you tell me where to find information about new features of
> >> mod_jk 1.2.20 ?
> >>
> >> For your information, our prototype is built from mod_jk 1.2.15. We
> >> could bring it to the 1.2.20.
> >>
> >> Regards.
> >>
> >> ----------------------------------------------------------------
> >> Anthony Vromant
> >> http://jonas.objectweb.org
> >> Bull, Architect of an Open World TM
> >> http://www.bull.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
>
> --
> ----------------------------------------------------------------
> Anthony Vromant
> http://jonas.objectweb.org
> Bull, Architect of an Open World TM
> http://www.bull.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Anthony Vromant <an...@bull.net>.
Hi Rainer,
First of all, thank you for these informations.
Here is the HTTP link for the Flash demonstration of our prototype :
https://wiki.objectweb.org/jonas/Upload.jsp?page=JOnASClusteringSmoothUpdateWebCluster
I am looking at the new features provided by mod_jk 1.2.20, the dynamic
configuration reloading is quite interesting.
We are going to bring our prototype to this new version.
In our prototype, when a new request is coming with a JSESSIONID cookie,
a request is sent to the worker (tomcat) for checking the validity (we
need to know whether the session is still alive).
Currently, the HTTP protocol is used for invoking tomcat rather than
AJP. The control at the tomcat side is done through an internal servlet
which accesses the MBean manager for getting the current sessions list.
Do you have any suggestion for improving that ?
Regards,
Anthony
Rainer Jung wrote:
> Hi Anthony,
>
> since your oce is based on 1.2.15 first the information for you, that
> between 1.2.15 and the released 1.2.19 there were a lot of features
> added. No old features has been dropped, so it should be feature
> compatible with 1.2.15. You can look at the changelog
>
> http://tomcat.apache.org/connectors-doc/changelog.html
>
> and maybe the easiest way is to scan the document
>
> http://tomcat.apache.org/connectors-doc/config/workers.html
>
> and for Apache
>
> http://tomcat.apache.org/connectors-doc/config/apache.html
>
> resp. for IIS
>
> http://tomcat.apache.org/connectors-doc/config/iis.html
>
> about new parameters, which you didn't know before. There are also
> hints in the docs, which of the params have been added in which version.
>
> Concerning 1.2.20 I'll make a tarball for testing including the docs
> most likely tonight. We changed a bit more, than was planned, so we
> give people a couple of days to report problems early, before we tag
> the release. Again, all changes will be contained in the configuration
> reference guide.
>
> Regards,
>
> Rainer
>
> Anthony Vromant wrote:
>> Rainer Jung wrote:
>>> Mladen Turk wrote:
>>>> Anthony Vromant wrote:
>>>>>
>>>>> Would it be possible to integrate such a feature in the original
>>>>> mod_jk ? If yes, we may contribute to the development by providing
>>>>> our code.
>>>>>
>>>>
>>>> There is no need to ask something like that.
>>>> Just like for any other patch bring in the code,
>>>> and we'll discuss, but it cannot be answered in advance.
>>>> Anyhow, according to the description it looks very interesting.
>>>>
>>>> Regards,
>>>> Mladen.
>>>
>>> Exactly the same from me. The upcoming release 1.2.20 will already
>>> include a lot of improvements in the jk status worker and we all
>>> think, that managing changes in a distributed 24x7 system already is
>>> a very important topic.
>>>
>>> Waiting for your proposals :)
>>>
>>> Rainer
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>> Glad to note that you are interested in this topic.
>>
>> I propose to send you as soon as possible a HTTP link towards a Flash
>> presentation of our prototype.
>> Thus you'll have a good overview of the feature.
>>
>> For the source code, we have to do some 'cleaning' work before being
>> able to submit it to you.
>>
>> Can you tell me where to find information about new features of
>> mod_jk 1.2.20 ?
>>
>> For your information, our prototype is built from mod_jk 1.2.15. We
>> could bring it to the 1.2.20.
>>
>> Regards.
>>
>> ----------------------------------------------------------------
>> Anthony Vromant
>> http://jonas.objectweb.org
>> Bull, Architect of an Open World TM
>> http://www.bull.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
----------------------------------------------------------------
Anthony Vromant
http://jonas.objectweb.org
Bull, Architect of an Open World TM
http://www.bull.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Anthony,
since your oce is based on 1.2.15 first the information for you, that
between 1.2.15 and the released 1.2.19 there were a lot of features
added. No old features has been dropped, so it should be feature
compatible with 1.2.15. You can look at the changelog
http://tomcat.apache.org/connectors-doc/changelog.html
and maybe the easiest way is to scan the document
http://tomcat.apache.org/connectors-doc/config/workers.html
and for Apache
http://tomcat.apache.org/connectors-doc/config/apache.html
resp. for IIS
http://tomcat.apache.org/connectors-doc/config/iis.html
about new parameters, which you didn't know before. There are also hints
in the docs, which of the params have been added in which version.
Concerning 1.2.20 I'll make a tarball for testing including the docs
most likely tonight. We changed a bit more, than was planned, so we give
people a couple of days to report problems early, before we tag the
release. Again, all changes will be contained in the configuration
reference guide.
Regards,
Rainer
Anthony Vromant wrote:
> Rainer Jung wrote:
>> Mladen Turk wrote:
>>> Anthony Vromant wrote:
>>>>
>>>> Would it be possible to integrate such a feature in the original
>>>> mod_jk ? If yes, we may contribute to the development by providing
>>>> our code.
>>>>
>>>
>>> There is no need to ask something like that.
>>> Just like for any other patch bring in the code,
>>> and we'll discuss, but it cannot be answered in advance.
>>> Anyhow, according to the description it looks very interesting.
>>>
>>> Regards,
>>> Mladen.
>>
>> Exactly the same from me. The upcoming release 1.2.20 will already
>> include a lot of improvements in the jk status worker and we all
>> think, that managing changes in a distributed 24x7 system already is a
>> very important topic.
>>
>> Waiting for your proposals :)
>>
>> Rainer
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
> Glad to note that you are interested in this topic.
>
> I propose to send you as soon as possible a HTTP link towards a Flash
> presentation of our prototype.
> Thus you'll have a good overview of the feature.
>
> For the source code, we have to do some 'cleaning' work before being
> able to submit it to you.
>
> Can you tell me where to find information about new features of mod_jk
> 1.2.20 ?
>
> For your information, our prototype is built from mod_jk 1.2.15. We
> could bring it to the 1.2.20.
>
> Regards.
>
> ----------------------------------------------------------------
> Anthony Vromant
> http://jonas.objectweb.org
> Bull, Architect of an Open World TM
> http://www.bull.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
--
kippdata informationstechnologie GmbH
Bornheimer Str. 33a
53111 Bonn
Tel. 0228/98549-0
Fax 0228/98549-50
www.kippdata.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Anthony Vromant <an...@bull.net>.
Rainer Jung wrote:
> Mladen Turk wrote:
>> Anthony Vromant wrote:
>>>
>>> Would it be possible to integrate such a feature in the original
>>> mod_jk ? If yes, we may contribute to the development by providing
>>> our code.
>>>
>>
>> There is no need to ask something like that.
>> Just like for any other patch bring in the code,
>> and we'll discuss, but it cannot be answered in advance.
>> Anyhow, according to the description it looks very interesting.
>>
>> Regards,
>> Mladen.
>
> Exactly the same from me. The upcoming release 1.2.20 will already
> include a lot of improvements in the jk status worker and we all
> think, that managing changes in a distributed 24x7 system already is a
> very important topic.
>
> Waiting for your proposals :)
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Glad to note that you are interested in this topic.
I propose to send you as soon as possible a HTTP link towards a Flash
presentation of our prototype.
Thus you'll have a good overview of the feature.
For the source code, we have to do some 'cleaning' work before being
able to submit it to you.
Can you tell me where to find information about new features of mod_jk
1.2.20 ?
For your information, our prototype is built from mod_jk 1.2.15. We
could bring it to the 1.2.20.
Regards.
----------------------------------------------------------------
Anthony Vromant
http://jonas.objectweb.org
Bull, Architect of an Open World TM
http://www.bull.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Rainer Jung <ra...@kippdata.de>.
Mladen Turk wrote:
> Anthony Vromant wrote:
>>
>> Would it be possible to integrate such a feature in the original
>> mod_jk ? If yes, we may contribute to the development by providing our
>> code.
>>
>
> There is no need to ask something like that.
> Just like for any other patch bring in the code,
> and we'll discuss, but it cannot be answered in advance.
> Anyhow, according to the description it looks very interesting.
>
> Regards,
> Mladen.
Exactly the same from me. The upcoming release 1.2.20 will already
include a lot of improvements in the jk status worker and we all think,
that managing changes in a distributed 24x7 system already is a very
important topic.
Waiting for your proposals :)
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Smooth applications migration in a J2EE cluster [mod_jk]
Posted by Mladen Turk <mt...@apache.org>.
Anthony Vromant wrote:
>
> Would it be possible to integrate such a feature in the original mod_jk
> ? If yes, we may contribute to the development by providing our code.
>
There is no need to ask something like that.
Just like for any other patch bring in the code,
and we'll discuss, but it cannot be answered in advance.
Anyhow, according to the description it looks very interesting.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org