the next server
and its response is simply added to the original stream from the client's
perspective.
That is just plain weird - and doesn't make sense to me at all in terms of
retry handling.
Any pointers/info on this would be much appreciated.
--
Jess Holle
P.S. The stream is gen
1/23/15 3:35 PM, André Warnier wrote:
Jess Holle wrote:
It seems that
java.net.InetAddress.getLoopbackAddress().getHostAddress() should
give the right answer -- if one is running with Java 7.
That said, is there a value that can be used for AJP's "address"
attribute that simply
It seems that java.net.InetAddress.getLoopbackAddress().getHostAddress()
should give the right answer -- if one is running with Java 7.
That said, is there a value that can be used for AJP's "address"
attribute that simply does the right thing here?
On 1/23/2015 1:38 PM, J
eaks of setting
127.0.0.1, yet I see indications that this won't fly in a pure IPv6
world. If a single value won't work, is there any good way to detect
which stacks are available via Java APIs during deployment?
--
Jess Holle
egard is the correct, standard/portable behavior?
--
Jess Holle
in Tomcat is
a non-starter.
[Yes, you could always reproduce the issue with Java connectors, but
that's painful and there are, of course, other reason for avoiding
native libraries, e.g. having to build them across the numerous
architectures one supports, rather than simple write-once
Sorry for the false alarm.
A little more digging showed that an old ECJ was getting used at runtime
-- because it had been thwacked into the runtime classpath. [Don't ask.]
It now works fine.
On 8/29/2014 9:14 AM, Mark Thomas wrote:
On 29/08/2014 14:56, Jess Holle wrote:
I have
ogled for these issues and found nothing helpful.
Should 7.0.55 work with Java 8 "as is"? If not, what is necessary to
make it work?
--
Jess Holle
later requests due to
recyling behavior!
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Thanks for the pointers -- I'll make good use of these.
As for #2, yes, the value of getQueryString() is as per expectations.
On 4/7/2014 1:01 PM, Konstantin Kolinko wrote:
Several quick thoughts
1. What is the value of
request.getAttribute("org.apache.catalina.parameter_parse_failed")
aft
50/53
configuration. It doesn't seem like it should be...
Tinkering with the internal state of the Request object, to set
parametersParsed to false and/or parameterMap to null in the debugger
doesn't help getParameterMap() succeed, though...
--
Jess Holle
On 4/7/2014 11:52 AM, Je
se it is relevant):
* Sprint 3.2.2
* JDK 7u51
--
Jess Holle
On 4/7/2014 10:21 AM, Jess Holle wrote:
We're seeing a bizarre failure of getParameterMap() wherein this
servlet API returns an empty map.
I thought we'd loused this up somehow via our servlet request filters,
but the
ation.
Any suggestions for getting to the bottom of this issue would be greatly
appreciated!
--
Jess Holle
Thanks!
On 7/10/2013 5:18 AM, Mark Thomas wrote:
On 10/07/2013 00:06, Jess Holle wrote:
Is there an ETA (in terms of both a version and rough date) for Tomcat
moving to the new spec versions introduced by Java EE 7?
Tomcat 8.
Implementation complete? Best guess is a couple of months. The
Is there an ETA (in terms of both a version and rough date) for Tomcat
moving to the new spec versions introduced by Java EE 7?
I'm talking about new servlet, JSP, EL, etc, specs, not about
non-web-tier stuff that's not even part of Tomcat.
--
to
many disparate environments can leverage WebSockets in any
substantive fashion.
--
Jess Holle
Note:
If you use various things like RMI and CMS GC and don't set one or two
key properties you'll always have a perm gen leak.
It's a nice feature of CMS :-)
On 5/21/2013 10:44 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Fachhoch,
On 5/21/13 10:53 AM, fa
On 5/3/2013 12:26 PM, Rainer Jung wrote:
On 03.05.2013 19:03, Jess Holle wrote:
On 5/3/2013 11:58 AM, Rainer Jung wrote:
Although AFAIR last time it couldn't do my favorite "quotient of
deltas", but until now I haven't found a standard tool doing that.
Average response ti
On 5/3/2013 11:58 AM, Rainer Jung wrote:
Although AFAIR last time it couldn't do my favorite "quotient of
deltas", but until now I haven't found a standard tool doing that.
Average response time in last intervall = delta(cumulatedResponseTime)/
delta(Re
http://blogs.cisco.com/security/linuxcdorked-faqs/ claims this is not a
cPanel vulnerability per se...
On 5/2/2013 6:22 AM, Darryl Lewis wrote:
"Last Friday (April 26), ESET and Sucuri simultaneously blogged about the
discovery of Linux/Cdorked, a backdoor impacting Apache servers running
cPane
On 2/4/2013 9:32 AM, Williams, Nick wrote:
-Original Message-
From: Jess Holle [mailto:je...@ptc.com]
...
It's that you can't make Java source code which /implements /JDBC interfaces
and make it compilable with both Java 6 and Java 7. The JDBC interfaces have
new methods
as one could simply
extend the wrapper class and override the necessary methods. This is a
lot easier to read than InvocationHandler code required by the dynamic
proxy approach. I'd bet that most who end up doing any substantive work
in this area end up creating their own reusable pass-thro
On 1/17/2013 12:36 PM, Violeta Georgieva wrote:
2013/1/17 Jess Holle
As part of testing Tomcat 7.0.35 when I moved to it, I run an Ant script
to pre-compile all our JSP pages.
When doing so I get a huge number of new failures which boil down to the
following stack trace. Any ideas here? I ca
As part of testing Tomcat 7.0.35 when I moved to it, I run an Ant script
to pre-compile all our JSP pages.
When doing so I get a huge number of new failures which boil down to the
following stack trace. Any ideas here? I can dig in to try to see
what's causing this, but this is new behavior.
Stick with the older ecj -- the newer one is broken.
On 1/10/2013 9:22 PM, Ralph Schaer wrote:
Hi
Tomcat 7.0.34 bumped ecj to version 4.2.1. But the pom file
of tomcat-embed-jasper still points to version 3.7.2 of ecj.
Is it safe to use ecj 3.7.2 with Tomcat 7.0.34?
It's unfortunately not possi
ls of ECJ, so
this really looks like an issue in ECJ.
--
Jess Holle
On 12/13/2012 1:07 AM, Mark Thomas wrote:
Jess Holle wrote:
I moved to Tomcat 7.0.34 -- apparently with inadequate testing / too
much trust.
Some JSPs that precompiled just fine with 7.0.33 and many previous
Tomcat versions n
y JDT compiler until proven otherwise.
--
Jess Holle
[jasper2] java.lang.ArrayStoreException:
org.eclipse.jdt.internal.compiler.ast.ReturnStatement
[jasper2] at
org.eclipse.jdt.internal.compiler.flow.FinallyFlowContext.recordNullReference(FinallyFlowContext.java:440)
[jasper2]
31 AM, Tony Anecito wrote:
Thanks Everyone. I agree on the security issue just seemed the last couple of
updates had no substance beyond just security. MS sends updates quite often but
I look forward to advances in other areas like performance ect.
Regards,
-Tony
--- On Fri, 8/31/12, Jess
Well, don't give Oracle too much credit -- or grief.
According to various articles (look them up, I didn't save the URLs),
they were notified of these vulnerabilities ~4 months ago.
Unfortunately several days ago serious attacks in the wild using these
vulnerabilities were discovered -- after
On 8/17/2012 3:18 PM, Konstantin Kolinko wrote:
2012/8/16 Jess Holle :
It appears that when one installs the groovy-all-2.0.1-indy.jar in a Tomcat
web app, BCEL chokes on the Java 7 specific byte-code therein ala
org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte
tag
On 8/16/2012 11:14 AM, Pid * wrote:
On 16 Aug 2012, at 17:10, Jess Holle wrote:
It appears that when one installs the groovy-all-2.0.1-indy.jar in a Tomcat web
app, BCEL chokes on the Java 7 specific byte-code therein ala
org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid
I completely exclude this jar from annotation scanning?
--
Jess Holle
The only way I know to address this obnoxious issue is to create your
own custom RMIClassLoaderSpi and install it early enough.
The custom RMIClassLoaderSpi is very simple:
public String getClassAnnotation( final Class cl )
{
return ( null ); // we don't need no stinking b
much more heap under 32-bit
addressing. How much depends on the OS, etc, but generally is much more
like 3GB.
--
Jess Holle
On 5/16/2012 8:04 AM, André Warnier wrote:
Miguel Gonzalez wrote:
there wasn't a limit of 32 bits OS for running JVM for more than 1.5 Gb?
Not exactly. I'
On 3/13/2012 8:49 AM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 3/13/12 8:47 AM, Jess Holle wrote:
So I read that the servlet 3.1 spec (and related EL specs, etc) is
to go final in "the second half of 2012".
Approximately when should we expec
So I read that the servlet 3.1 spec (and related EL specs, etc) is to go
final in "the second half of 2012".
Approximately when should we expect a Tomcat that supports the new specs
-- in terms of number of months after the specs' final release?
How can this be a "low" priority JVM bug!?!
On 3/7/2012 11:21 AM, Konstantin Kolinko wrote:
2012/3/7 Kari Scott:
We are using Tomcat 7.0.23 with jdk1.6.0_30 on Solaris 10, mod_ajp 1.3 and
Apache 2.2.21.
I'm using the following code to retrieve memory information from our JMX server:
Objec
On 3/1/2012 9:50 AM, Jess Holle wrote:
In some cases we are seeing:
2012-03-01 18:43:55,624 ERROR [ajp-bio-9920-exec-2]
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/PDMPJL100].[jsp]
- Servlet.service() for servlet [jsp] in context with path
[/PDMPJL100] threw exception
ig (>65K) error. This is maddening when
nothing has changed -- the compiler should produce the same results in
any case. This particular issue is hard enough to reproduce that I've
not had a chance to try it with 3.7.1.
--
Jess Holle
-
On 2/5/2012 2:53 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 2/5/12 1:23 PM, Jess Holle wrote:
Certainly this is an optional / quality of implementation feature.
I'm perfectly aware that other form-based authentication solutions
will not save
On 2/5/2012 12:22 PM, Konstantin Kolinko wrote:
2012/2/5 Jess Holle :
Also it strikes me that maxSavePostSize should really be backed up by a use
of a SoftReference in SavedRequest.
This would allow one to allow relatively large POST bodies to be saved
unless/until this threatened to consume
On 2/5/2012 12:04 PM, André Warnier wrote:
Hi.
I've just been following this thread, and this is not about the
problem per se, but a comment about the overall design of the
application.
The fact that you do a POST without being authenticated, and that you
rely on the server to save the POST
On 2/5/2012 11:24 AM, Jess Holle wrote:
On 2/5/2012 11:22 AM, Jess Holle wrote:
On 2/5/2012 11:15 AM, Konstantin Kolinko wrote:
I think this issue is specific to AJP.
For HTTP connectors a similar issue was noted and fixed here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9
I
On 2/5/2012 11:22 AM, Jess Holle wrote:
On 2/5/2012 11:15 AM, Konstantin Kolinko wrote:
I think this issue is specific to AJP.
For HTTP connectors a similar issue was noted and fixed here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51940#c9
I think adding the following line to
Tomcat. I just don't
want to maintain this patch forever (nor have everyone else suffer from
this bug in the AJP case).
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional comma
On 2/5/2012 10:38 AM, Jess Holle wrote:
Diving in deeper, I see that AbstractAjpProcessor.action() is setting
the bodyBytes perfectly for the ActionCode.REQ_SET_BODY_REPLAY case here.
After that is done, however, I don't see anything that tries to read
AbstractAjpProcessor.body
On 2/5/2012 9:43 AM, Jess Holle wrote:
On 2/5/2012 9:26 AM, Konstantin Kolinko wrote:
build.xml:
build.properties.default:
compile.debug=true
Thus debug information should already be there.
I usually start with setting some breakpoints. In your case take a
look at FormAuthenticator
and where they are called from.
Thanks. I've already seen via a heap dump that the request is saved
with the correct content body. So now the only question that remains is
why it does not get restored.
--
Jess Holle
---
On 2/5/2012 8:29 AM, Konstantin Kolinko wrote:
2012/2/5 Jess Holle:
I've done all the basic troubleshooting tweaks I can think of, trying 7.0.25
and 7.0.23, switching my web.xml back to the 2.5 spec level, reducing from a
combination of 2 JNDI realms to 1, cranking lots of loggers up to
ess I either ignore this (ouch) or really dig into debugging
Tomcat's internals (which while far easier than trying to do so with
httpd is still not where I'd wanted to spend my time).
--
Jess Holle
On 2/4/2012 5:49 PM, Jess Holle wrote:
Yes, I'm using Tomcat authentication. Yes
Yes, I'm using Tomcat authentication. Yes, the issue is after
authentication on the POST retry.
On 2/4/2012 12:27 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 2/3/12 5:59 PM, Jess Holle wrote:
Or could this be getting loused up by having a se
On 2/3/2012 5:26 PM, Konstantin Kolinko wrote:
2012/2/4 Jess Holle:
I posted a query recently wherein I thought that POST data was being lost
*only* if the user had been authenticated, their session timed out, and then
they POST'ed to a URL requiring authentication -- thus having their re
Or could this be getting loused up by having a servlet request filter
that calls getParameterMap() first thing?
I'd *assume* not -- as that would be pretty hokey...
On 2/3/2012 4:53 PM, Jess Holle wrote:
In case this makes any difference this is with the AJP BIO connector.
On 2/3/2012
In case this makes any difference this is with the AJP BIO connector.
On 2/3/2012 4:51 PM, Jess Holle wrote:
I posted a query recently wherein I thought that POST data was being
lost *only* if the user had been authenticated, their session timed
out, and then they POST'ed to a URL requ
etty sure I was having similar issues
with 7.0.25 as well. [No, I didn't really downgrade -- I'm just working
in a context that's still using 7.0.23 at the moment.]
I'm left wondering what could be causing the issue.
--
Jess Holle
P.S. The lack of wisdom of setting ma
d out. In that case, Tomcat fails to deliver the POST data.
I assume this is a known issue/limitation. If not, is there some
configuration setting I'm missing or some such? This is with Tomcat 7.0.23.
--
Jess Holle
--
t natural and useful
Java language feature. I'd argue all servlet engines should really
provide this feature for just this reason. That said, I can live with A.
--
Jess Holle
You get an error when that's what's occurring, though.
On 12/7/2011 12:55 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 12/6/11 6:17 PM, Jess Holle wrote:
Okay, I now notice this plainly stated in the documentation for
JNDIRealm (which I'
On 12/7/2011 11:47 AM, Mark Thomas wrote:
On 07/12/2011 17:04, Jess Holle wrote:
I note that in recent versions of Tomcat (e.g. 7.0.23), the session id
changes when you do a form-based authentication.
I do not see any sort of notice via anything one can listen to via the
servlet API to receive
n see.]
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
2:24 PM, Jess Holle wrote:
I should have noted that this is with Tomcat 7.0.23, but it seemed
unlikely to be JVM (Java 6 Update 29) or OS (Windows 7) specific.
Of course given that I found that the documentation clearly states this
behavior, I suspect this is longstanding Tomcat behavior
/ Tomcat behaves this way. If one quickly
restarts Tomcat for some reason and session data is preserved, you
really don't want all the users to have to login again do you?
--
Jess Holle
On 12/6/2011 7:05 PM, André Warnier wrote:
Jess Holle wrote:
When doing a graceful shutdown of Tomcat
Okay, I now notice this plainly stated in the documentation for
JNDIRealm (which I'm using):
The cached user is *not* saved and restored across sessions
serialisations.
That seems a bit odd...
On 12/6/2011 5:12 PM, Jess Holle wrote:
When doing a graceful shutdown of Tomcat, the ses
?
Intentional? Configurable?
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
x27;t
one that could possibly be used by a login form or
2. Add some other custom header to your response. If it's not there
but you got a 200, then something hijacked the response -- quite
probably a login form.
--
Jess Holle
On 9/1/2011 5:49 PM, Mabry Tyson wrote:
Summary: When re
ardless of internal classloader logic.
Overall I'm pretty confident that things are okay here -- especially as
we've been using and testing this configuration for quite some time now.
--
Jess Holle
-
To unsubscribe, e-
arale, Charles R wrote:
From: Jess Holle [mailto:je...@ptc.com]
Subject: Re: Slower start with Tomcat 7.0.14 and higher
Well the classloaders are clearly hierarchical, so only one Class
instance is loaded. The fact that both ClassLoaders can see the jar
does not result in 2 Class objects
I think we
On 6/22/2011 10:16 AM, Jess Holle wrote:
On 6/22/2011 9:08 AM, Mark Thomas wrote:
Another issue is that WEB-INF/lib is visible to the parent classloader
embedding Tomcat and to Tomcat as part of the web application and thus
I'm probably getting double scanning -- though really Tomcat shou
ge in size from 48K to 46MB. Only 3 jars are over 25MB in size.
--
Jess Holle
te File object.
Is there any danger -- other than worse performance in use cases I don't
have -- in me patching my own Tomcat to always use FileUrlJar? Should
this perhaps be a config option? Or possibly a config option based on
file size? [FileUrlJar may only be faster for larger jars fro
On 6/20/2011 5:05 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 6/20/2011 5:47 PM, Jess Holle wrote:
On 6/20/2011 4:35 PM, Christopher Schultz wrote:
Maybe you could move /some/ of them?
The libraries in question are actually loaded by the application
On 6/20/2011 4:35 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jess,
On 6/20/2011 3:41 PM, Jess Holle wrote:
On 6/20/2011 2:16 PM, Mark Thomas wrote:
It should have improved for the majority of use cases in 7.0.14 but at
the price of making it worse for JARs
reasonable despite scanning all our jars) cannot be re-attained.
I might go there anyway for *some* of our jars, but I will likely want
to start doing more via annotations and less via web.xml as well -- and
would like to minimize the startup performance penalty entailed in doing so.
--
On 6/20/2011 2:41 PM, Jess Holle wrote:
On 6/20/2011 2:16 PM, Mark Thomas wrote:
It should have improved for the majority of use cases in 7.0.14 but at
the price of making it worse for JARs in CATALINA_[HOME_BASE]/lib.
7.0.16 should have returned scanning of JARs in CATALINA_[HOME_BASE]/lib
to
such a profile here in a bit...
--
Jess Holle
y like to get this resolved and get back to the
previous performance. If, however, #1 explains much of the degradation,
then I'll need to look into excluding jars from scanning, etc.
--
Jess Holle
, not counting the Tomcat calls before/after this), but not so
easy for an asynchronous request...
--
Jess Holle
On 5/18/2011 6:31 AM, Dan Checkoway wrote:
I've messed around a bit, and I figured out a more reliable way to do
it...but it's pretty nasty. Basically I'm iterating a
some other
means for a filter to interject itself between the final write to a
response and stream/socket closure?
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mai
ingletons, e.g. data
sources, where you belatedly discover you want a cardinality of 'n'
rather than 1.
--
Jess Holle
On 5/13/2011 8:56 AM, Caldarale, Charles R wrote:
From: JanAa [mailto:jan.aage...@norse-solutions.com]
Subject: Re: Multiple context paths for single deployment
What I want
get mod_jk working well with the event MPM sounds
like a good thing for us to do.
If mod_event is going to be the default, then ensuring mod_jk works well
with it sounds like a rather critical thing to do.
--
Jess Holle
-
To unsu
On 5/3/2011 6:14 AM, Jess Holle wrote:
On 5/3/2011 3:18 AM, Mark Thomas wrote:
As I write this it occurs to me that an AJP-NIO connector would be a big
help to you here. I don't know how much work that would be to write but
with the refactoring already completed for Tomcat 7 it might
this list could answer (Mladen?), but
realize there are relatively few involved in mod_jk code.
--
Jess Holle
in Tomcat at all?
In Apache, I note that there are noises about broader/better support for
the mod_event MPM worker. Does mod_jk work with mod_event there to
reduce the threads required in Apache?
--
Jess Holle
If you want compression here, then just do it in a servlet filter based on
Accept-Encoding thus resulting in compression in Tomcat and the stream
remaining compressed all the way to the client.
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Fri 4/1/2011 5:20
If you use a recent version of Java 6 both jconsole and VisualVM come
with the JDK (at least in most cases -- VisualVM does not run on or come
with IBM's JVM).
On 3/14/2011 2:55 PM, Jess Holle wrote:
Or for a somewhat better UI and more capability overall, VisualVM.
[Note that Visua
Or for a somewhat better UI and more capability overall, VisualVM.
[Note that VisualVM's MBean tree is via a plug-in, so you need to
install the plug-in before you get this functionality.]
On 3/14/2011 2:42 PM, Leon Rosenberg wrote:
thanx guys.
Leon
On Mon, Mar 14, 2011 at 11:34 AM, Mikolaj
me whether this works against the 65K limit or not.
Note the last 2 results are essentially identical (I didn't compare byte
counts).
Yet when I try this last configuration with the JSP that goes over 65K
it fails with JDT and succeeds with javac.
--
Jess Holle
On 3/12/2011 9:50 AM, J
On 3/11/2011 6:04 AM, Jess Holle wrote:
On 3/11/2011 3:22 AM, Mark Thomas wrote:
The obvious difference is that Tomcat 6 compilation targets Java 5
whereas Tomcat 7 targets Java 6. For a simple test JSP:
Tomcat 6 (1.5) - 3,488
Tomcat 7 (1.5) - 3,530 +1%
Tomcat 7 (1.6) - 3,668 +6%
The 1% will
ac and see what that does
-- just as a point of comparison.
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
by use of generics...
Anyway, I guess the page owners will have to try to clean things up.
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
On 3/10/2011 10:34 PM, Caldarale, Charles R wrote:
From: Jess Holle [mailto:je...@ptc.com]
Subject: Re: JSP class size increase in Tomcat 7
Yes, both Java 6 Update 24.
Just to verify, are both instances Tomcat running in the same JVM mode (-client
or -server)? (That shouldn't affec
Yes, both Java 6 Update 24.
Both using the same doc-base, file paths, etc. I renamed the old Tomcat
directory and put the new one in its place.
On 3/10/2011 10:01 PM, Bob Hall wrote:
Jess,
--- On Thu, 3/10/11 at 7:10 PM, Jess Holle wrote:
P.S. This was with Tomcat 7.0.10.
On 3/10/2011
P.S. This was with Tomcat 7.0.10.
On 3/10/2011 9:10 PM, Jess Holle wrote:
I've been looking at moving to Tomcat 7 from Tomcat 6.
Most things look good.
I have been surprised by one thing, however: Tomcat 7 produces larger
JSP class files than Tomcat 6 from the same JSP source files
aside from that I don't have any bright ideas here.
--
Jess Holle
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
By the way, I did some more testing and though I would have sworn that
destroy() prevented any further requests in Tomcat 6.0.x it also appears
to allow at least 1 additional request.
On 3/9/2011 1:44 PM, Jess Holle wrote:
On 3/9/2011 1:40 PM, Mark Thomas wrote:
On 09/03/2011 18:50, Mark
On 3/9/2011 1:40 PM, Mark Thomas wrote:
On 09/03/2011 18:50, Mark Thomas wrote:
On 09/03/2011 15:47, Jess Holle wrote:
What's more troublesome to me is that with every approach I've tried at
least 1 request still gets through. In some cases this request works
normally. In other
On 3/9/2011 12:50 PM, Mark Thomas wrote:
On 09/03/2011 15:47, Jess Holle wrote:
When invoking stop() and then destroy() the destroy() succeeds
[something I missed in my original post], but an exception is still logged:
2011-03-09 09:29:21,939 ERROR [RMI TCP Connection(21)-10.196.0.84
to take a given Tomcat out of
the rotation rather than just make a simple Java call in Tomcat to tell
it to stop taking new requests.
--
Jess Holle
On 3/9/2011 9:09 AM, Mark Thomas wrote:
On 09/03/2011 15:06, Jess Holle wrote:
So there's no way to do this from the Tomcat side?
The process e
odd behavior for a single
request after the stop/destroy().
--
Jess Holle
On 3/9/2011 8:50 AM, Mladen Turk wrote:
On 03/09/2011 03:26 PM, Jess Holle wrote:
P.S. I certainly want to finish processing requests that are already
being processed -- I want a graceful shutdown.
It's a tw
P.S. I certainly want to finish processing requests that are already
being processed -- I want a graceful shutdown.
On 3/9/2011 8:16 AM, Jess Holle wrote:
I want to stop all incoming requests at a given point. I am running
Tomcat within a larger process and I want to stop accepting new
1 - 100 of 185 matches
Mail list logo
