Mark,
On 3/14/24 07:57, Mark Thomas wrote:
On 12/03/2024 13:47, Christopher Schultz wrote:
Greg and Mark,
On 3/12/24 05:00, Greg Huber wrote:
On 11/03/2024 18:17, Christopher Schultz wrote:
Mark,
On 3/10/24 08:49, Mark Thomas wrote:
On 10/03/2024 10:50, Greg Huber wrote:
Hello,
Using htt
On 12/03/2024 13:47, Christopher Schultz wrote:
Greg and Mark,
On 3/12/24 05:00, Greg Huber wrote:
On 11/03/2024 18:17, Christopher Schultz wrote:
Mark,
On 3/10/24 08:49, Mark Thomas wrote:
On 10/03/2024 10:50, Greg Huber wrote:
Hello,
Using http://tomcat/manager-app/text/reload?path=/
Wh
Greg and Mark,
On 3/12/24 05:00, Greg Huber wrote:
On 11/03/2024 18:17, Christopher Schultz wrote:
Mark,
On 3/10/24 08:49, Mark Thomas wrote:
On 10/03/2024 10:50, Greg Huber wrote:
Hello,
Using http://tomcat/manager-app/text/reload?path=/
When I reload an application (in java), I get a rep
Running it on the browser I get
Content-Type : text/plain;charset=utf-8
On 11/03/2024 18:17, Christopher Schultz wrote:
Mark,
On 3/10/24 08:49, Mark Thomas wrote:
On 10/03/2024 10:50, Greg Huber wrote:
Hello,
Using http://tomcat/manager-app/text/reload?path=/
When I reload an application (
Mark,
On 3/10/24 08:49, Mark Thomas wrote:
On 10/03/2024 10:50, Greg Huber wrote:
Hello,
Using http://tomcat/manager-app/text/reload?path=/
When I reload an application (in java), I get a reply
OK - Reloaded application at context path [/]
but when the application is not present I get this
OK, thanks. Something I can deal with in my app.
On Sun, 10 Mar 2024 at 12:49, Mark Thomas wrote:
> On 10/03/2024 10:50, Greg Huber wrote:
> > Hello,
> >
> > Using http://tomcat/manager-app/text/reload?path=/
> >
> > When I reload an application (in java), I get a reply
> >
> > OK - Reloaded ap
On 10/03/2024 10:50, Greg Huber wrote:
Hello,
Using http://tomcat/manager-app/text/reload?path=/
When I reload an application (in java), I get a reply
OK - Reloaded application at context path [/]
but when the application is not present I get this reply:
FAIL - No context exists named [/]
I
Hello,
Using http://tomcat/manager-app/text/reload?path=/
When I reload an application (in java), I get a reply
OK - Reloaded application at context path [/]
but when the application is not present I get this reply:
FAIL - No context exists named [/]
Is it intentional that the fail shows the
Ivano,
On 8/4/21 18:22, Ivano Luberti wrote:
Hello, in order to improve management of our servers I would like to
implement the ability to timely reload Tomcat TLS configuration so to
make tomcat aware of renewed certificates
Do you want to do this from script or something else?
I have seen
Hello, in order to improve management of our servers I would like to
implement the ability to timely reload Tomcat TLS configuration so to
make tomcat aware of renewed certificates
I have seen that in the manager web application I can reload TLS
configuration with the Re Read button in the Re-
s re-established in order to pick-up any new TLS
> configuration -- specifically, reloading the key store and trust
> store for the connection .
>
> What's the best way to do that?
>
>> Do you want the connections that are checked out to clients to
>> be force-closed, so they wi
by Tomcat) have TLS configuration including client certificates,
trusted server certificates, etc.
I'd like to be able to "bounce" the DataSource so that each Connection
is re-established in order to pick-up any new TLS configuration --
specifically, reloading the key store and trust
e-established in order to pick-up any new TLS
> configuration -- specifically, reloading the key store and trust
> store for the connection .
>
> What's the best way to do that?
>
> It looks like Tomcat will automatically register a JMX bean for
> the DataSource under
> /C
this DataSource pool (using dbcp2 as provided
>by Tomcat) have TLS configuration including client certificates,
>trusted server certificates, etc.
>
>I'd like to be able to "bounce" the DataSource so that each Connection
>is re-established in order to pick-up any new TL
rtificates,
trusted server certificates, etc.
I'd like to be able to "bounce" the DataSource so that each Connection
is re-established in order to pick-up any new TLS configuration --
specifically, reloading the key store and trust store for the connection
.
What's the best
On 27/03/17 11:39, André Warnier (tomcat) wrote:
On 27.03.2017 10:56, Mark Thomas wrote:
On 27/03/17 09:26, Olaf Kock wrote:
Other options that I can envision is to change Jasper's implementation
to keep serving a compiled JSP until the replacement has been properly
compiled and loaded in th
On 27.03.2017 10:56, Mark Thomas wrote:
On 27/03/17 09:26, Olaf Kock wrote:
Other options that I can envision is to change Jasper's implementation
to keep serving a compiled JSP until the replacement has been properly
compiled and loaded in the background (e.g. not having compilation block
fu
On 27/03/17 09:26, Olaf Kock wrote:
> Other options that I can envision is to change Jasper's implementation
> to keep serving a compiled JSP until the replacement has been properly
> compiled and loaded in the background (e.g. not having compilation block
> further requests to the same page). I
equest end up throwing 504 errors.
>
> We are considering to pre-compile the JSPs before deploying them to
> the server. The problem is that we are not able to find any option to
> force Tomcat to hot reload ONLY the updated classes. All the different
> reload options that we have tested en
problem is that we are not able to find any option to force Tomcat to
hot reload ONLY the
updated classes. All the different reload options that we have tested
end up reloading all
the webapp (which means 80s of downtime for us).
Is there any recommended option to manage this? Does somebody have
JSPs before deploying them to the server.
The
problem is that we are not able to find any option to force Tomcat to hot
reload ONLY the
updated classes. All the different reload options that we have tested end up
reloading all
the webapp (which means 80s of downtime for us).
Is there any
problem is that we are not able to find any option to force
Tomcat to hot reload ONLY the updated classes. All the different reload
options that we have tested end up reloading all the webapp (which means
80s of downtime for us).
Is there any recommended option to manage this? Does somebody
r
> > Tomcat server. There is a requirement here (for the reasons of
> > automating administrative tasks) to enable starting, stoping and
> > reloading individual applications from Linux command line
> >
> > I am using your documentation on Apache Tomcat Manager a
/www.avios.com/>
>
>
>
>
>
> From:"Yudin, Ilya"
> To:users@tomcat.apache.org,
> Date:14/07/2015 15:58
> Subject:Command line requests for starting/reloading/stoping
> applications are not working in Tomcat 7.0.57 Manager
ere (for the reasons of
> automating administrative tasks) to enable starting, stoping and
> reloading individual applications from Linux command line
>
> I am using your documentation on Apache Tomcat Manager at the
> following URL:
> http://tomcat.apache.org/tomcat-
apache.org,
Date: 14/07/2015 15:58
Subject:Command line requests for starting/reloading/stoping
applications are not working in Tomcat 7.0.57 Manager
Hello,
I'm running Apache Tomcat 7.0.57 on RHEL 6.6 servers for CCI NewsGate
editorial system which uses around 20 applications pe
Hello,
I'm running Apache Tomcat 7.0.57 on RHEL 6.6 servers for CCI NewsGate
editorial system which uses around 20 applications per Tomcat server. There
is a requirement here (for the reasons of automating administrative tasks)
to enable starting, stoping and reloading individual applica
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Alireza,
Please don't hijack threads by replying to an existing post with a new
question. Instead, create a completely new message to
users@tomcat.apache.org with your question.
- -chris
On 8/19/13 8:19 AM, Alireza Fattahi wrote:
> Hi, I am using
On Aug 19, 2013, at 8:19 AM, Alireza Fattahi wrote:
> Hi,
> I am using Tomcat 6.0.
Which one? Try to be more specific.
> The context is set to autoreload.
> When I change the JSP the pages are publish and the context are not restart.
This is different from context reloading.
Hi,
I am using Tomcat 6.0. The context is set to autoreload.
When I change the JSP the pages are publish and the context are not restart.
When I change the java files the context is restarting .
I am using struts 2 framework and extending its template framework. The
new template files, which are
2012/10/5 Anjib Mulepati :
>
> Quick question. If I made change to (\META_INF\context.xml) file do i have
> to restart tomcat server to load changes?
>
You need to undeploy & deploy your web application.
Recent versions of Tomcat 7 should do that automatically if autoDeploy
is enabled on the Host
Hi All,
Quick question. If I made change to (\META_INF\context.xml) file do i
have to restart tomcat server to load changes?
Thanks
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail
>
> Hello,
I'm using Tomcat 7 embedded mode in my app. I've had a difficult time
figuring out how to actually reload the context using WatchedResources and
class reloading from WEB-INF/classes/.
What I've noticed is that using the Tomcat class addWebApp() utility
func
due to previous errors
>> log4j:ERROR LogMananger.repositorySelector was null likely due to
>> error in class reloading, using NOPLoggerRepository.
>>
>>
>> This error is very short and I googled online for this error, but can
>> not figure out either. how to make
0-Jun-2011 9:19:24 AM org.apache.catalina.core.StandardContext start
> SEVERE: Context [/testPhoenix] startup failed due to previous errors
> log4j:ERROR LogMananger.repositorySelector was null likely due to
> error in class reloading, using NOPLoggerRepository.
>
>
> This error is very short a
SEVERE: Context [/testPhoenix] startup failed due to previous errors
log4j:ERROR LogMananger.repositorySelector was null likely due to
error in class reloading, using NOPLoggerRepository.
This error is very short and I googled online for this error, but can
not figure out either. how to make this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/14/2010 11:42 AM, Jane Muse wrote:
> Chris wrote:
>
>
> We didn't change in context.xml from how it was
> installed in tomcat 6.0.18. The default is commented out. But thanks for
> the info.
That's not what Subversion says:
http://
at in order
for the webapp to deploy, correct? I think we'll do it this way in the
production environment.
mailto:ch...@christopherschultz.net]
Sent: Thursday, October 14, 2010 7:54 AM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
-BEGI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
On 10/14/2010 11:18 AM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Subject: Re: Disable class monitoring for reloading container classes
>
>> It's probably no
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Re: Disable class monitoring for reloading container classes
> It's probably not necessary to comment-out the
> as the context should not be reloadable if you set reloadable="true",
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/13/2010 5:41 PM, Jane Muse wrote:
> We have a directory called COMPANY_NAME/tomcat that is CATALINA_BASE.
> I sent the contents of CATALINA_BASE/conf/context.xml in the email
> below.
Great. It's probably not necessary to comment-out the
List
Subject: RE: Disable class monitoring for reloading container classes
That was me in another thread. Here's what I stated:
"It just occurred to me that I don't think anyone's asked if these are
net-mounted file systems. I've seen this timestamp-shifting before
ems are set to
different timezones (or DST settings)."
Jeff
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, October 13, 2010 1:21 PM
> To: Tomcat Users List
> Subject: Re: Disable class monitoring for reloading
d it to reloadable="false" and
restarted tomcat. Now the app does not get reloaded! Fixed. Thanks to
all.
Jane
-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Sent: Wednesday, October 13, 2010 12:57 PM
To: Tomcat Users List
Subject: RE: Disable
> From: Jane Muse [mailto:jm...@aldon.com]
> Subject: RE: Disable class monitoring for reloading container classes
> Here's my context.xml:
>
>
That may not be illegal syntax for XML, but it certainly is confusing. Better
to do this:
> We are not defining our
t: Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/13/2010 1:51 PM, Jane Muse wrote:
> I found that reloadable="false" does not suppress tomcat from watching
> if files change in WEB-INF/lib, even though the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/13/2010 1:51 PM, Jane Muse wrote:
> I found that reloadable="false" does not suppress tomcat from watching
> if files change in WEB-INF/lib, even though the docs say it does:
Please log a bug. Note that bugs logged against old versions o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/13/2010 1:40 PM, Jane Muse wrote:
> Thanks for the java program Chris, I ran it on the version of the O/S
> where we get the problem and got results that show a last modified
> date that differs by one hour when the time changes due to DST
t]
Sent: Tuesday, October 12, 2010 11:16 AM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/9/2010 11:09 AM, Jane Muse wrote:
> My understanding from the docs is that reloading="false&quo
monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 10/10/2010 9:09 AM, André Warnier wrote:
> What would be really nice, is if someone wrote a quick Java equivalent
> to the perl script I submitted.
See below. There's actually more code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/9/2010 11:09 AM, Jane Muse wrote:
> My understanding from the docs is that reloading="false" means you
> can't drop in a war file while tomcat is running and expect it to
> deploy.
No, ("reloading" is m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jane,
On 10/9/2010 12:02 AM, Jane Muse wrote:
> Chris wrote:
>
>> It's too bad the
>> log doesn't show the old timestamp versus the new one.
>
> The log shows the timestamp for the file
I meant that it would be nice if the log said something like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 10/10/2010 9:09 AM, André Warnier wrote:
> What would be really nice, is if someone wrote a quick Java equivalent
> to the perl script I submitted.
See below. There's actually more code than absolutely necessary, but
it's more straightforwa
day, October 08, 2010 5:04 PM
> To: Tomcat Users List
> Subject: Re: [OT] Disable class monitoring for reloading container
> classes
>
> Jeffrey Janner wrote:
> ..
> God I really hate DST. Don't let me get started on a rant.)
> ..
> Right. As someone once asked
tp://security.it.ray.com/antivirus/extensions.html
http://security.it.ray.com/news/2007/zipfiles.html
Should you have any questions or difficulty with these instructions, please
contact the Help Desk at 877.844.4712
---
Caldarale, Charles R wrote:
> From: André Warnier [mailto:a...@ice-sa.com]
From: André Warnier [mailto:a...@ice-sa.com]
Subject: Re: Disable class monitoring for reloading container classes
> thanks for the perl program.
I would not introduce yet another variable into situation, since perl is not
involved in any way with your Tomcat installation, and we don
Jane Muse wrote:
André,
thanks for the perl program. I tried it and got
>
qsh: 001-0019 Error found searching for command showmodified.pl. No such path or directory.
You may need to adjust the first line of the program, to point to the executable perl
interpreter.
Use "which perl" to
ane
-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Saturday, October 09, 2010 7:19 AM
To: Tomcat Users List; Jane Muse
Subject: Re: Disable class monitoring for reloading container classes
Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:ch..
> I have reloading="false" and autoDeploy="false" set in the context.xml
> and server.xml.
That's even weirder. How do you deploy Tomcat? Perhaps Tomcat isn't
using the server.xml you think it is using.
My understanding from the docs is that reloading="
Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Subject: Re: Disable class monitoring for reloading container classes
The timestamp of the file should be /the/ timestamp for the
file, and shouldn't be affected by the current DST settings.
Chris wrote:
'/WEB-INF/lib/ant-1.6.5.jar' was modified; Date is now: Sun Aug 22
> 19:51:04 PDT 2010 Was: Sun Aug 22 18:51:04 PDT 2010
> INFO ContainerBackgroundProcessor[StandardEngine[Catalina]]
> org.apache.catalina.core.StandardContext - Reloading this Context has
> star
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Re: Disable class monitoring for reloading container classes
> The timestamp of the file should be /the/ timestamp for the
> file, and shouldn't be affected by the current DST settings.
> The ti
22
> 19:51:04 PDT 2010 Was: Sun Aug 22 18:51:04 PDT 2010
> INFO ContainerBackgroundProcessor[StandardEngine[Catalina]]
> org.apache.catalina.core.StandardContext - Reloading this Context has
> started
> DEBUG ContainerBackgroundProcessor[StandardEngine
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 10/8/2010 5:20 PM, André Warnier wrote:
> In that case,
> - Jane's experience is still incomprehensible
> - the possible bug I mentioned cannot happen
+1 +1
> - but the logic used by Tomcat seems wasteful : aren't these a lot of
> files fo
mailto:ch...@christopherschultz.net]
Sent: Friday, October 08, 2010 8:07 AM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pid,
On 10/7/2010 5:52 PM, Pid wrote:
> On 07/10/2010 22:30, Christop
Jeffrey Janner wrote:
..
God I really hate DST. Don't let me get started on a rant.)
..
Right. As someone once asked me : "Why could they not leave the time as God gave us,
he ?"
-
To unsubscribe, e-mail: users-unsubscr...@tom
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Friday, October 08, 2010 3:56 PM
> To: Tomcat Users List
> Subject: Re: Disable class monitoring for reloading container classes
>
> -BEGIN PGP SIGNED MESSAGE-
&g
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 10/8/2010 2:12 PM, André Warnier wrote:
0 1 2 3 4 5
!--!--!x-!--!x-! ... (you get
the idea)
At time t1, nothing has changed,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 10/8/2010 2:12 PM, André Warnier wrote:
> 0 1 2 3 4 5
> !--!--!x-!--!x-! ... (you get
> the idea)
>
> At time t1, nothing has changed, and nothing happens.
Christopher Schultz wrote:
...
Technically speaking, the modification date isn't checked against the
context startup date it's checked against the last modified date
that was recorded by the ClassLoader. That makes sense because you might
have a JAR file that's been updated but the timestam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pid,
On 10/7/2010 5:52 PM, Pid wrote:
> On 07/10/2010 22:30, Christopher Schultz wrote:
>
>> If the above logic is the actual implementation, then the only time
>> you'd have a problem is when you've deployed a webapp during the window
>> covered by t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pid,
On 10/8/2010 4:44 AM, Pid wrote:
> On 08/10/2010 01:19, Jane Muse wrote:
>> If I changed the system time zone not to change with daylight savings
>> time, then it would be off by an hour. I don't think our customers would
>> like that. Or am I mi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark,
On 10/8/2010 4:44 AM, Mark Thomas wrote:
> On 08/10/2010 01:11, Jane Muse wrote:
>> This happens with both DST and standard time changes. What's interesting
>> is if we go back in time to Oct 29 2006, it does not occur. From March
>> 2007 forwar
Jane Muse wrote:
If I changed the system time zone not to change with daylight savings
time, then it would be off by an hour. I don't think our customers would
like that. Or am I misunderstanding your comment?
Maybe Pid's comment was partly "tongue-in-cheek".
You did not misunderstand, but of
gt; Jane
>
> -Original Message-
> From: Pid [mailto:p...@pidster.com]
> Sent: Thursday, October 07, 2010 8:23 AM
> To: Tomcat Users List
> Subject: Re: Disable class monitoring for reloading container classes
>
> On 06/10/2010 20:39, Jane Muse wrote:
>>
On 08/10/2010 01:11, Jane Muse wrote:
> This happens with both DST and standard time changes. What's interesting
> is if we go back in time to Oct 29 2006, it does not occur. From March
> 2007 forward, every fall and spring we get the error when the
> application reloads. The DST time change rules
tober 07, 2010 8:23 AM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
On 06/10/2010 20:39, Jane Muse wrote:
> There's a backgroundProcessor method in tomcat that checks whether
> container classes need to be reloaded, and checks for session
&
zone.
Thanks much,
Jane
-Original Message-
From: Pid [mailto:p...@pidster.com]
Sent: Thursday, October 07, 2010 2:52 PM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
On 07/10/2010 22:30, Christopher Schultz wrote:
> Jane,
>
> On 10/
to disable this method, like you can disable
>> class reloading for the context with reloadable="false"? I'm using
>> tomcat 6.0.18 on an IBM i (OS400) version V6R1. When daylight savings
>> time hits, our application gets reloaded, and the following
On 07/10/2010 21:34, André Warnier wrote:
> Jane Muse wrote:
> ..
>> The reason why there's a problem when the application gets reloaded is
> due to we are loading a JNI native library that the application
> requires. According to the following link, section 11.2.4, the JVM does
> not allow a JNI n
, like you can disable
> class reloading for the context with reloadable="false"? I'm using
> tomcat 6.0.18 on an IBM i (OS400) version V6R1. When daylight savings
> time hits, our application gets reloaded, and the following statements
> are in cat
Jane Muse wrote:
..
> The reason why there's a problem when the application gets reloaded is due to we are
loading a JNI native library that the application requires. According to the following
link, section 11.2.4, the JVM does not allow a JNI native library to be loaded by more
than one class
Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Thursday, October 07, 2010 3:26 AM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
Jane Muse wrote:
> André - you are correct. We actually modified "autoDeploy" attri
On 06/10/2010 20:39, Jane Muse wrote:
> There's a backgroundProcessor method in tomcat that checks whether
> container classes need to be reloaded, and checks for session
> expirations. Is it possible to disable this method, like you can disable
> class reloading for the contex
those times the application(s) get reloaded ?
(In fact, I strongly suspect that it may happen only /at most/ once a year, and then only
in very specific circumstances. It is your changing of the system time which triggers the
reloading, but it would probably never happen in reality on a producti
2010 1:34 PM
To: Tomcat Users List
Subject: Re: Disable class monitoring for reloading container classes
Jane Muse wrote:
> There's a backgroundProcessor method in tomcat that checks whether
> container classes need to be reloaded, and checks for session
> expirations. Is it possibl
Jane Muse wrote:
There's a backgroundProcessor method in tomcat that checks whether
container classes need to be reloaded, and checks for session
expirations. Is it possible to disable this method, like you can disable
class reloading for the context with reloadable="false"? I
There's a backgroundProcessor method in tomcat that checks whether
container classes need to be reloaded, and checks for session
expirations. Is it possible to disable this method, like you can disable
class reloading for the context with reloadable="false"? I'm using
tomca
will be simple nodes or lbcluster.
I`ve made another patch.
Added JkWorkersFileReload apache setting, by default disabled.
It works if using JkWatchdogInterval only.
Adding a call to wc_reload to jk_status.c (just like mount file reloading)
sometimes crashes apache process.
http://huksley.sdot.
jk_status.c (just like mount file reloading)
sometimes crashes apache process.
http://huksley.sdot.ru/wp-content/uploads/2010/09/mod_jk-1.2.30-reload-workers-patch2.zip
With kindest personal regards,
Ruslan Gainutdinov
On Tue, Sep 7, 2010 at 1:54 AM, Rainer Jung wrote:
> On 06.09.2010 22:04, Rus
On 06.09.2010 22:04, Ruslan Gainutdinov wrote:
Thanks for info, I`ll check it out tomorrow.
AFAIK, on windows, it is not shared memory but some sort of pool.
Isn`t it dynamically grows when needed?
No. Until version 1.2.26 you had to configure a fixed max size, from
which the needed memory was
Thanks for info, I`ll check it out tomorrow.
AFAIK, on windows, it is not shared memory but some sort of pool.
Isn`t it dynamically grows when needed?
I am trying to create dynamic discovery of workers.
I know there is mod_cluster, however, it is not very stable in Tomcat.
And it does not give me
On 09/06/2010 05:54 PM, Ruslan Gainutdinov wrote:
Hello!
this error is particularly confusing and afaik, occurs
in call to jk_shm_alloc_ajp_worker, which in turn fails in
jk_shm.c:768 - jk_shm_alloc(p, JK_SHM_AJP_WORKER_SIZE);
i wonder,
maybe shared memory/or pool is readonly after initial se
Hello!
I am trying to implement dynamic reloading of workers on top of mod_jk
1.2.30 + apache 2.2.
However, I am getting strange errors related to shared memory and others.
== Initial design decisions ==
- Reloading is checked during watchdog, wc_maintain phase. This way
all connections can be
Caldarale, Charles R said on 8.7.2010 3:31:
From: Caldarale, Charles R
Subject: RE: Webapp reloading issue and intermittent 404 errors
Given the test on lines 129-130, it is impossible to have a -1 at line
131 - unless there's a JVM bug.
6u21 was just released tonight, so you might give
> From: michel [mailto:compu...@videotron.ca]
> Subject: manual reloading a class
If this has anything to do with Tomcat, it's not clear.
> I don't want to use the automatic class reload for performance reasons,
What "automatic class reload" are you referring to?
I don't want to use the automatic class reload for performance reasons, but is
there some code or such that will reload a specific class?
Thank you!
Am 17.07.2010 12:56, schrieb Mark Thomas:
> On 17/07/2010 09:50, Marco Ehrentreich wrote:
>> Accordingly to the documentation an implementation of ObjectFactory
>> should be accessed each time a web application looks it up with its JNDI
>> key. But that's definitely not the case here.
>
> What doc
On 17/07/2010 09:50, Marco Ehrentreich wrote:
> Accordingly to the documentation an implementation of ObjectFactory
> should be accessed each time a web application looks it up with its JNDI
> key. But that's definitely not the case here.
What documentation?
Mark
--
Hi guys,
I'm stuck with a JNDI resource object factory problem. Hopefully you can
help me out with this issue.
My idea was to provide multiple web applications running inside a Tomcat
instance with configuration properties from config files located outside
the WAR file of the applications. I'm cu
1 - 100 of 279 matches
Mail list logo
