Dan,
On 6/20/23 18:03, Christopher Schultz wrote:
Dan,
On 6/16/23 12:54, Dan McLaughlin wrote:
Does anyone have any advice on implementing Context Versioning (parallel
deployment) in Tomcat? It seems to have been a feature for quite some
time.
Is it stable? What are the typical issues
Dan,
On 6/16/23 12:54, Dan McLaughlin wrote:
Does anyone have any advice on implementing Context Versioning (parallel
deployment) in Tomcat? It seems to have been a feature for quite some time.
Is it stable? What are the typical issues people run into? JMX issues?
Classloader issues?
It
Hello Dan,
> -Ursprüngliche Nachricht-
> Von: Dan McLaughlin
> Gesendet: Freitag, 16. Juni 2023 18:54
> An: Tomcat Users List
> Betreff: Words of Wisdom re: Context Versioning - Parallel Deployment
>
> Does anyone have any advice on implementing Context
Does anyone have any advice on implementing Context Versioning (parallel
deployment) in Tomcat? It seems to have been a feature for quite some time.
Is it stable? What are the typical issues people run into? JMX issues?
Classloader issues?
I've tried to do a parallel deployment wit
gal state exception when using parallel
> deployment in tomcat 7
> https://www.mail-archive.com/users@tomcat.apache.org/msg133549.html
> since I wasn't able to find a solution we kinda avoided using parallel
> deployment on production enviroment.Recently I got back to that issue(which
Hi everyone! About a year ago I asked the following question on the users-list
about getting a illegal state exception when using parallel deployment in
tomcat 7
https://www.mail-archive.com/users@tomcat.apache.org/msg133549.html
since I wasn't able to find a solution we kinda avoided
Ĺ
Hello everyone!I have only recently discovered a wonderful posibility of
parallel deployment in tomcat 7 and it works great for jsp and most of the
servlets . however there is a small problem .Amongs regular jsp and servlets we
have around 300 different reports developed with BIRT designer
do you use JMX for ?
Thanks again
Regards
Gilles
-Message d'origine-
De : HeeGu Lee [mailto:elfhazardw...@gmail.com]
Envoyé : mardi 27 novembre 2018 08:36
À : Tomcat Users List
Objet : Re: Connection pool and parallel deployment problem
Dear Gilles,
I apologize for the delay i
You can try HikariCP, it is mentionned in the Spring documentation
-Message d'origine-
De : HeeGu Lee [mailto:elfhazardw...@gmail.com]
Envoyé : mardi 27 novembre 2018 10:28
À : Tomcat Users List
Objet : Re: Connection pool and parallel deployment problem
I'm glad to solve pr
I'm glad to solve problem.
But I am concerned that the C3p0 is not updated since 2015.
Let's hope for a better library.
Bye~
2018년 11월 27일 (화) 오후 6:20, Gilles SCHLIENGER 님이
작성:
> Thanks,
>
> I don't have this problem using C3p0
>
> Parallel deployment is working fi
Thanks,
I don't have this problem using C3p0
Parallel deployment is working fine so far, especially now that we will use
connection pools configured inside the webapp (no more context xml file)
Regards
Gilles
-Message d'origine-
De : HeeGu Lee [mailto:elfhazardw...@gmail.co
, you must set JMX bean name dynamically.
>
> I hope this helps.
>
>
> 2018년 11월 27일 (화) 오전 2:03, Chris Cheshire 님이 작성:
>
> > On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER
> > wrote:
> > >
> > > Hi,
> > > I understand your needs, but wha
t; Envoyé : mardi 27 novembre 2018 08:36
> À : Tomcat Users List
> Objet : Re: Connection pool and parallel deployment problem
>
> Dear Gilles,
>
> I apologize for the delay in reply.
>
> I make simple webapp and upload to github. In project, my test result is
> included.
mardi 27 novembre 2018 08:36
À : Tomcat Users List
Objet : Re: Connection pool and parallel deployment problem
Dear Gilles,
I apologize for the delay in reply.
I make simple webapp and upload to github. In project, my test result is
included.
https://github.com/elfhazardwork/dbcp2-test
Tom
l.com]
Envoyé : lundi 26 novembre 2018 18:04
À : Tomcat Users List
Objet : Re: Connection pool and parallel deployment problem
On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER
wrote:
>
> Hi,
> I understand your needs, but what is your problem, since you don't use
> parallel deploymen
M Gilles SCHLIENGER
> wrote:
> >
> > Hi,
> > I understand your needs, but what is your problem, since you don't use
> parallel deployment ?
> > Your connections are not closed but they will not be recreated when you
> deploy your webapp again, so there should be
On Mon, Nov 26, 2018 at 9:58 AM Gilles SCHLIENGER
wrote:
>
> Hi,
> I understand your needs, but what is your problem, since you don't use
> parallel deployment ?
> Your connections are not closed but they will not be recreated when you
> deploy your webapp again, so the
Hi,
I understand your needs, but what is your problem, since you don't use parallel
deployment ?
Your connections are not closed but they will not be recreated when you deploy
your webapp again, so there should be no problem ?
Gilles
-Message d'origine-
De : Chri
I'm interested in what solution there is for this because I have the
exact same problem but without parallel deployment.
[snip]
On Mon, Nov 26, 2018 at 3:54 AM Gilles SCHLIENGER
wrote:
>
> Hi Christopher,
>
> Thanks for your email.
>
> About connection pools not
ailto:ch...@christopherschultz.net]
Envoyé : samedi 24 novembre 2018 17:19
À : users@tomcat.apache.org
Objet : Re: Connection pool and parallel deployment problem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gilles,
On 11/23/18 05:07, Gilles SCHLIENGER wrote:
> Thanks Mark for your answer
>
> Her
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Gilles,
On 11/23/18 05:07, Gilles SCHLIENGER wrote:
> Thanks Mark for your answer
>
> Here is what I found in case someone has the same problem.
>
> When you use parallel deployment, you should not use a connexion
> pool in th
Thanks Mark for your answer
Here is what I found in case someone has the same problem.
When you use parallel deployment, you should not use a connexion pool in the
context.xml file
Once the connexions are opened, they stay opened until Tomcat shuts down,
whatever configuration you try.
So
Are you talking about parallel deployment or connection pools ?
Parallel deployment is in Tomcat since Tomcat 7
Gilles
-Message d'origine-
De : HeeGu Lee [mailto:elfhazardw...@gmail.com]
Envoyé : mercredi 21 novembre 2018 13:24
À : Tomcat Users List
Objet : Re: Connection poo
On 21/11/2018 11:00, Gilles SCHLIENGER wrote:
> Hi all,
>
> We are using Tomcat 9 and parallel deployment.
>
> I use a connection pool defined in the xml context (myApp##1.xml,
> myApp##2.xml in my exemple)
>
> I have the following problem :
> - I have myApp##1.war
such features.
Both Tomcat and DB vendors are not going to fix it.
It's not a tragedy, it's just a comedy.
2018년 11월 21일 (수) 오후 8:00, Gilles SCHLIENGER 님이
작성:
> Hi all,
>
> We are using Tomcat 9 and parallel deployment.
>
> I use a connection pool defined in the xml con
Hi all,
We are using Tomcat 9 and parallel deployment.
I use a connection pool defined in the xml context (myApp##1.xml, myApp##2.xml
in my exemple)
I have the following problem :
- I have myApp##1.war deployed using a connection pool (configured in
myApp##1.xml)
- I deploy myApp##2.war
: Tomcat Users List
Objet : RE: Default context.xml with parallel deployment
Thank you very much Mark for your answer.
I will look into the xml entities, I did not know about this feature.
I was wondering if a feature like having a "myapplication.xml.default" could be
a good idea to
d'origine-
De : Mark Thomas [mailto:ma...@apache.org]
Envoyé : jeudi 8 novembre 2018 23:37
À : users@tomcat.apache.org
Objet : Re: Default context.xml with parallel deployment
On 08/11/2018 20:45, Gilles SCHLIENGER wrote:
> Hi everyone,
>
> We are using Tomcat 9.0.8.
>
of the application.
Thanks a lot again
Regards
Gilles
-Message d'origine-
De : Jäkel, Guido [mailto:g.jae...@dnb.de]
Envoyé : vendredi 9 novembre 2018 08:22
À : 'users@tomcat.apache.org'
Objet : RE: Default context.xml with parallel deployment
Dear Giles,
what aspects do
Thursday, November 08, 2018 9:46 PM
>To: users@tomcat.apache.org
>Subject: Default context.xml with parallel deployment
>
>Hi everyone,
>
>We are using Tomcat 9.0.8.
>
>We are using xml context files in
>$CATALINA_BASE/conf/[enginename]/[hostname]/ to store the database co
On 08/11/2018 20:45, Gilles SCHLIENGER wrote:
> Hi everyone,
>
> We are using Tomcat 9.0.8.
>
> We are using xml context files in
> $CATALINA_BASE/conf/[enginename]/[hostname]/ to store the database connexion
> information.
>
> When using parallel deployment, I und
Hi everyone,
We are using Tomcat 9.0.8.
We are using xml context files in $CATALINA_BASE/conf/[enginename]/[hostname]/
to store the database connexion information.
When using parallel deployment, I understand that you should use for specific
context xml files :
- for myapplication##1.war
On 04/10/18 13:24, Tomáš Bleša wrote:
> As I understand tomcat documentation, parallel deployment is intended to be
> used to smoothly rollout new versions of webapp. I've looked in source code
> and it's written such that there is probably no way to custimize selection o
As I understand tomcat documentation, parallel deployment is intended to be
used to smoothly rollout new versions of webapp. I've looked in source code and
it's written such that there is probably no way to custimize selection of
proper context version. If session is invalid then newe
Hi Mark,
i have extended Shiro's default sid generator (JavaUuidSessionIdGenerator),
providing ids according to your suggestion, but unfortunately we obtain the
same behaviour.
After deploying the new app upgrade, users on the old release are logged out
again.
--
Sent from: http://tomcat.10.x6.
On 4 December 2017 10:25:35 GMT+00:00, malbinola wrote:
>Hi All,
>we have been using the fantastic parallel deployment feature (PD) for
>years
>but now, after upgrading to Apache Shiro's native session management,
>it
>don't work anymore.
>
>Let's suppose th
Hi All,
we have been using the fantastic parallel deployment feature (PD) for years
but now, after upgrading to Apache Shiro's native session management, it
don't work anymore.
Let's suppose that we have a deployed app named app##01.war on which we have
several logged users. If we
On 31 May 2017 at 10:11, Mark Thomas wrote:
>
> >>
> >>
> > would a feature request be accepted for this that there can be a cookie
> set
> > where that "load balancer" would also look at?
> > and that cookie always make sure that it goes to the context it started
> > from as long as that contex
On 31/05/17 08:38, Johan Compagner wrote:
>>
>>
>> It depends. If the URL in the HTTP UPGRADE request includes the session
>> ID, and that session ID is still valid in ##1, then the WebSocket
>> request will be handled by ##1.
>>
>> Mark
>>
>>
> would a feature request be accepted for this that the
>
>
> It depends. If the URL in the HTTP UPGRADE request includes the session
> ID, and that session ID is still valid in ##1, then the WebSocket
> request will be handled by ##1.
>
> Mark
>
>
would a feature request be accepted for this that there can be a cookie set
where that "load balancer" wou
In a similar situation, I do the following :
* go full stateless, use no session ;
* configure WS client to frequently reconnect
* use atmosphere with an internal JMS backend, such as ActiveMQ, to share data
transparently between parallely deployed versions.
With Atmosphere, you avoid losing mess
>
> > But now i have websockets, if i connect to ##1 first and i have the end
> > point there
> > Then i add a ##2 version of the context
> > then i guess a new user that opens a websocket will go to ##2
> > but if the existing user does a refresh in the browser then it will also
> > suddenly go to
On 30/05/17 11:09, Johan Compagner wrote:
> Hi,
>
> if i read this:
>
> http://tomcat.apache.org/tomcat-8.5-doc/config/context.html#Parallel_deployment
>
> then i see it will go to the "old" version of a war based on session
> information
> i guess this is jsessionid?
>
> So a refresh in the br
Hi,
if i read this:
http://tomcat.apache.org/tomcat-8.5-doc/config/context.html#Parallel_deployment
then i see it will go to the "old" version of a war based on session
information
i guess this is jsessionid?
So a refresh in the browser or another request with the jsessionid will go
to the vers
Mark,
you where right. I was able to track down the root cause: race condition
between copy the .war and the .xml, when the .xml finishes copying first,
the context wont start (.war not found).
Thanks.
2017-03-02 11:58 GMT-03:00 Mark Thomas :
> On 02/03/17 13:13, Tiago Oliveira wrote:
> > Hel
On 02/03/17 13:13, Tiago Oliveira wrote:
> Hello,
>
> i guess the title describes our situation. I pasted the stack trace from
> catalina.out in a gist:
> https://gist.github.com/tiagojco/2e05203095e262c559d2f679dd6b42ff
That stack trace is a failure to clean up properly. The real error
occurred
Hello,
i guess the title describes our situation. I pasted the stack trace from
catalina.out in a gist:
https://gist.github.com/tiagojco/2e05203095e262c559d2f679dd6b42ff
While performing "hot deployment", the second context does not start (see
stack trace). After restarting the enviroment, both g
do happen to create dummy sessions (we do this by touching
req.getSession()) you'll notice that the old version of the webapp won't
undeploy while there are sessions still out there.
CG
On Wed, Sep 14, 2016 at 9:12 AM, Felipe Jaekel wrote:
> Hi,
>
> I've been using paralle
Hi,
I've been using parallel deployment successfully with JSF based webapps for
some years.
Now I'd like to use it with some web service based webapps (CXF). I noticed
on Tomcat Manager that these webapps doesn't create sessions on the
requests.
I use *undeployOldVersions="
I need some help:
My web application has an upload file function. These files can be huge.
While the file is uploading, the upload class spawns a new thread to send
status updates to the client's progress bar. This works fine even for the
most giant files except when we want to make a par
of container-in-a-container thing. It creates its
> own
> > classloader and pulls in all of its jar libraries dynamically. The
> problem
> > is that it uses a java.net.URL to target the files. This would be fine
> > except for the problem that the folder name, when using p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chris,
On 10/1/15 5:26 PM, Chris Gamache wrote:
> I didn't know that you could do that for parallel deployment!
>
> A quick follow-up set of questions:
>
> Up until now I was counting on manager and tomcat's unpackWA
Not always predictable (you expect no more than 99 versions and finally have).
Can be against conventions.
Le 2 octobre 2015 13:07:15 GMT+02:00, David kerber a
écrit :
>On 10/2/2015 4:33 AM, l.pe...@senat.fr wrote:
>> Hi.
>>
>> I am using parallel deployment to upgra
On 10/2/2015 4:33 AM, l.pe...@senat.fr wrote:
Hi.
I am using parallel deployment to upgrade my webapps with no downtime.
I just have a small issue / question on how the latest version is selected.
As far as I understand, the container select the latest version by
lexicographically ordering
Hi.
I am using parallel deployment to upgrade my webapps with no downtime.
I just have a small issue / question on how the latest version is selected.
As far as I understand, the container select the latest version by
lexicographically ordering the version string.
So if
webapp##1.0.51
and
would be fine
> except for the problem that the folder name, when using parallel
> deployment, is
>
> /path/to/yourWar##12345
>
> So (from org.apache.axis2.deployment.util.Utils)
>
> public static URL[] getURLsForAllJars(URL url, File tmpDir) {
> FileInputStream
I didn't know that you could do that for parallel deployment!
A quick follow-up set of questions:
Up until now I was counting on manager and tomcat's unpackWAR handling the
nuts and bolts of the deploy process. Even though the warfile is named
yourWar-2.war, if I allow tomcat to
wn classloader and pulls in all of its jar libraries
> dynamically. The problem is that it uses a java.net.URL to target
> the files. This would be fine except for the problem that the
> folder name, when using parallel deployment, is
>
> /path/to/yourWar##12345
>
> So (from org
ld be fine
except for the problem that the folder name, when using parallel
deployment, is
/path/to/yourWar##12345
So (from org.apache.axis2.deployment.util.Utils)
public static URL[] getURLsForAllJars(URL url, File tmpDir) {
FileInputStream fin = null;
InputStream
ll servers are the same
> >>
> > 2. Some subset users get a different version of the application
> >>
> >
> > All servers would have all versions of the app, thats the whole
> > point :) I.e. Instead of Server 1 - 3: App Version 001 Server 4 -
> > 6:
rvers are the same
>>
> 2. Some subset users get a different version of the application
>>
>
> All servers would have all versions of the app, thats the whole
> point :) I.e. Instead of Server 1 - 3: App Version 001 Server 4 -
> 6: App Version 002
>
> I would have
r 1 - 3: App Version 001
>Server 4 - 6: App Version 002
>
>I would have
>Server 1-6: App Version 001 + 002
>
>Parallel deployment makes this possible and simple to use.
As far as I understand (and use it on a daily basis), parallel deployment
allows to upgrade a webapp to a ne
ns of the app, thats the whole point :)
I.e.
Instead of
Server 1 - 3: App Version 001
Server 4 - 6: App Version 002
I would have
Server 1-6: App Version 001 + 002
Parallel deployment makes this possible and simple to use.
> Sounds like they can't co-exist without some kind of compro
ed as if nothing.
>
> I could deploy two different context for this, or use two different
> Tomcats on the same machine, it's just that parallel deployment
> seems like a perfect fit.. except I cannot control the traffic ;)
You have competing requirements:
1. All servers are
all my servers to be identical.
If one fails, or is taken out of load balancer due to maintenance, I want
everything to proceed as if nothing.
I could deploy two different context for this, or use two different Tomcats
on the same machine, it's just that parallel deployment seems like a
perf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
George,
On 9/24/15 5:59 PM, George Sexton wrote:
> On 9/24/2015 4:35 AM, Linus Brimstedt wrote:
>> Hello,
>>
>> Opening an old thread here regarding controlling which version of
>> a web app a request ends up at in a parallell deployment
>> scenari
On 9/24/2015 4:27 PM, André Warnier (tomcat) wrote:
On 24.09.2015 23:59, George Sexton wrote:
...
Couldn't you have your load balancer send x% to one instance, and
1-x% to the other
instance?
Wait, I didn't get this.
Say that x = 20.
So we send 20% to instance A.
Then we send (1 - 20)% =
On 24.09.2015 23:59, George Sexton wrote:
...
Couldn't you have your load balancer send x% to one instance, and 1-x% to the
other
instance?
Wait, I didn't get this.
Say that x = 20.
So we send 20% to instance A.
Then we send (1 - 20)% = -19%, to instance B.
So together, instance A and instan
have to be aware of this?
(related question on serverfault:
http://serverfault.com/questions/723944/can-you-redirect-a-user-to-a-specific-version-in-tomcats-parallel-deployment
)
br
/Linus
On 21 July 2015 at 19:21, Christopher Schultz
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
the behaviour
through a header which I can impose in a load balancer or proxy fronting
Tomcat. Other suggestions are welcome.
(related question on serverfault:
http://serverfault.com/questions/723944/can-you-redirect-a-user-to-a-specific-version-in-tomcats-parallel-deployment
)
br
/Linus
On 21
ly not necessary.
We have some GWT-based components where the version number of the .js
files is very important, and the browser can't just use the old
version of the script with new data and vice-versa. So we do version
those URLs, but it's not done at the context-path level.. it's
>> BTW: The reason I'm asking is because that transparent shift from
>> one app release to the next doesn't play along well with any caches
>> (browser, caching proxies, CDNs etc.): When a shift to the next app
>> release occurs, I generally need the client browsers to fetch a
>> fresh copy of all
1. Any patches
> not requiring reload could be deployed with #001,#002, but you
> would need to deploy two or more of the same webapp to get
> different urls: /webapp-1.0 and /webapp-1.1. The whole idea of the
> parallel deployment is to get the old version of the webapp
> undeploy
different urls: /webapp-1.0 and /webapp-1.1. The whole idea of the parallel
deployment is to get the old version of the webapp undeployed asap. If you have
different logical versions that need to remain... Well, using the management
servlet you can programmatically undeploy your obsolete webap
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hartmut,
On 7/19/15 2:49 PM, Hartmut Honisch wrote:
> Hi everyone,
>
> I'm using Tomcat's parallel deployment feature, and I wonder
> whether there's a way to request a specific version of my webapp.
>
> Let&#x
2015-07-19 22:49 GMT+03:00 Hartmut Honisch :
> Hi everyone,
>
> I'm using Tomcat's parallel deployment feature, and I wonder whether
> there's a way to request a specific version of my webapp.
>
> Let's say I have a WAR named myapp##001.war deployed on my serv
Hi everyone,
I'm using Tomcat's parallel deployment feature, and I wonder whether
there's a way to request a specific version of my webapp.
Let's say I have a WAR named myapp##001.war deployed on my server and just
deployed a new WAR myapp##002.war.
Requests to http:/m
;> http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html.
>>>>
>>>> It mostly works fine. On occasion (twice a week or so) there
>>>> will be one or more servers which didn't get the message that
>>>> a new war was deployed (contin
ke a
>> real weakness in the scheme. That makes me think I'm missing
>> something obvious. If it works like it says it should in the docs
>> I shouldn't be having this issue. Either there's something wrong
>> with my config or there's a problem with tomc
s which didn't get the message that a new war
> was deployed (continuous deployment using the tomcat parallel
> deployment scheme. e.g. theapp##007.war) and they happily continue
> to run the old version of the war.
I presume you have checked that the "affected" nodes are run
be one or
> more servers which didn't get the message that a new war was deployed
> (continuous deployment using the tomcat parallel deployment scheme. e.g.
> theapp##007.war) and they happily continue to run the old version of the
> war.
>
> In a farm deployment scenario, th
s which didn't get the message that a new war
> was deployed (continuous deployment using the tomcat parallel
> deployment scheme. e.g. theapp##007.war) and they happily continue
> to run the old version of the war.
>
> In a farm deployment scenario, the master node will announce to
che.org/tomcat-7.0-doc/cluster-howto.html.
It mostly works fine. On occasion (twice a week or so) there will be one or
more servers which didn't get the message that a new war was deployed
(continuous deployment using the tomcat parallel deployment scheme. e.g.
theapp##007.war) and they happily continu
On Mon, Nov 24, 2014 at 5:48 PM, Chris Gamache wrote:
> Tomcat 7 ... Working with parallel deployment, tomcat servers in my farm
> are getting out-of-sync, not getting new versions of war files deployed to
> the main tomcat. What could be going wrong and how can I fix it?
>
Tomcat 7 ... Working with parallel deployment, tomcat servers in my farm
are getting out-of-sync, not getting new versions of war files deployed to
the main tomcat. What could be going wrong and how can I fix it?
Pleez Help!
> From: Bjørn T Johansen [mailto:b...@havleik.no]
> Subject: Parallel deployment and failed to stop a thread.
> The web application [##02] appears to have started a thread named
> [Mojarra-WebResourceMonitor-1-thread-1] but has failed to stop it.
> Is this a problem with T
I am trying out parallell deployment but there seems to be a memory leak? when
undeploying the old version.. I get the following message in the log..:
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web
application [##02] appears to have started a thread named
[M
> From: Leo Donahue - OETX [mailto:leodona...@mail.maricopa.gov]
> Subject: RE: parallel deployment question
> > http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming
> "If a version is specified then the context path remains unchanged (the path
> b
>-Original Message-
>From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
>Subject: RE: parallel deployment question
>
>> From: Leo Donahue - OETX [mailto:leodona...@mail.maricopa.gov]
>> Subject: RE: parallel deployment question
>
>> I guess I t
> From: Leo Donahue - OETX [mailto:leodona...@mail.maricopa.gov]
> Subject: RE: parallel deployment question
> I guess I thought it would get the path name from the name of the .war file.
Read the doc:
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming
> deploying d
>-Original Message-
>From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
>Subject: RE: parallel deployment question
>
>> From: Leo Donahue - OETX [mailto:leodona...@mail.maricopa.gov]
>> Subject: parallel deployment question
>
>> When I par
> From: Leo Donahue - OETX [mailto:leodona...@mail.maricopa.gov]
> Subject: parallel deployment question
> When I parallel deploy demo##001.war, in my servlet, when I use:
> servletContext.getContextPath(); it prints: /demo
> Why doesn't it print /demo##001 ?
Because
I experimented with deploying a demo.war and a demo##001.war
When I parallel deploy demo##001.war, in my servlet, when I use:
servletContext.getContextPath(); it prints: /demo
Why doesn't it print /demo##001 ?
If I do: servletContext.getRealPath(getServletName()); it prints:
C:\ApacheTom
expected delay
>>>>> when switching to new version of an application when using
>>>>> the parallel deployment process? I'm trying to do timings
>>>>> right now with a single Hello World JSP and sometimes there
>>>>> is a delay of up to
he expected delay
>>>> when switching to new version of an application when using
>>>> the parallel deployment process? I'm trying to do timings
>>>> right now with a single Hello World JSP and sometimes there
>>>> is a delay of up to 4 seconds w
t mechanism involves placing a new context.xml file
in {tomcat.root}/conf/Catalina/localhost/ which has the docbase property
set to an already exploded WAR.
>
>> Does anyone know if it is expected for there to be a slight hiccup
>> in response times when the applications are deployed via
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jeremy,
On 7/5/13 11:24 AM, Majors, Jeremy wrote:
> For a simple web application, what is the expected delay when
> switching to new version of an application when using the parallel
> deployment process? I'm trying to do timings
For a simple web application, what is the expected delay when switching to new
version of an application when using the parallel deployment process? I'm
trying to do timings right now with a single Hello World JSP and sometimes
there is a delay of up to 4 seconds when the new version o
Atenciosamente,
Demetrio Carvalho.
11-9.4992-6018
Mark Thomas escreveu:
>On 01/07/2013 22:00, Caldarale, Charles R wrote:
>>> From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: Tomcat
>>> 7.0.27 on Mac OSX Lion -- Is it Possible to use Tomcat Parallel
>>> De
> From: Majors, Jeremy [mailto:jmaj...@tribune.com]
> Subject: Re: Tomcat 7.0.27 on Mac OSX Lion -- Is it Possible to use Tomcat
> Parallel Deployment when the Context Name is Different than the WAR Name
> It appears to be working after I added the information provided by Mark
>
1 - 100 of 206 matches
Mail list logo
