rotation of catalina.out on restart but no truncation
Hi, we've got an effekt on catalina.out. We don't use hot deployment. Instead we stop and start our tomcat for installing new Version. The restart causes rotation of catalina.out, but does not truncate. How can we solve this? Meik - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Handling requests when under load - ACCEPT and RST vs non-ACCEPT
On 11/09/2012 02:16 AM, Pid wrote: On 08/11/2012 15:03, Asankha C. Perera wrote: Hi Mark what happens if some other process grabs the port in the meantime: what is Tomcat supposed to do then? In reality I do not know of a single client production deployment that would allocate the same port to possibly conflicting services, that may grab another's port when its suffering under load. Just because it wouldn't cause a problem for a limited subset of Tomcat users - your clients - does not mean that it would not cause problems for other Tomcat users. I cannot see any other issues of turning off accepting - and I am curious to know if anyone else could share their views on this - considering real production deployments The problems have already been explained to you. Another process could use the port. I would consider such production deployment as a risk - a Tomcat crash, or even a restart might end up in a soup if another process starts using the port in the mean time.. It is not uncommon for monitoring tools to attempt to (re)start a service when it is observed not to be listening on its designated port. But that could happen even now, if the backlog fills and connections are being reset as seen currently cheers asankha -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.blogspot.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: This is just plain ... odd.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Russ,
On 11/8/12 6:05 PM, Russ Kepler wrote:
> On Thursday, November 08, 2012 07:36:20 PM Lyallex wrote:
>
>> The only difference between the two executions is the fact that
>> the test code executes in it's own instance of the JVM whereas
>> the other execution runs in an instance shared with the
>> container.
>>
>> I accept that the behaviour may be undefined even though it is
>> consistently repeatable in both environments but surely given
>> everything else being equal the results should be the same ... or
>> maybe I'm just losing the plot.
>
> No, you're right but just missing some small difference in the
> environments.
>
> I'd verify that you get the same input data in the same order in
> both cases, and that you're starting with the same size container
> [...]
After writing a bench test that I couldn't get to fail, your comment
here tripped a thought in my brain: the "container" size. So, I added
an element to my list of Strings and boom: failure. It turns out that
the collection size doesn't matter: I just hadn't been iterating
enough, so I added a loop that will run until the initial sorted order
doesn't match the re-sorted order (with shuffles in between).
Lyallex, see the code below: it will fail after a few iterations to
produce the same element ordering. Switch from BrokenSorter to
WorkingSorter and you'll find that it runs forever.
Are you *sure* that your database always returns the items in the same
order? If you plan on sorting alphabetically later, why bother sorting
by id when fetching? Unless you are really sorting by id when
fetching, the data can come back in any order. It may *often* be in
entry-sequenced order, but it is certainly not guaranteed to be.
The code below shows that, without any funny business, the sort can
work sometimes and not in others.
Enjoy,
- -chris
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
import java.util.Comparator;
import java.util.List;
public class SortTest
{
public static void main(String[] args)
{
String[] fruits = new String[] {
"Apples",
"Bananas",
"Coconuts",
"Dates",
"Eggplants",
"Figs",
"Grapefruits",
"Honeydews",
"Ilamas",
"Jambolans",
"Kepels",
"Lemons",
"Miscellaneous",
"Nectarines"
};
List fruitList = Arrays.asList(fruits);
Comparator sorter = new BrokenSorter();
System.out.println("Initial order: " + fruitList);
Collections.sort(fruitList, sorter);
System.out.println("Sort 1: " + fruitList);
List saved = new ArrayList(fruitList);
int i = 1;
do
{
Collections.shuffle(fruitList);
Collections.sort(fruitList, sorter);
System.out.println("Sort " + (++i) + ": " + fruitList);
}
while(fruitList.equals(saved));
System.out.println("Stopped after " + i + " iterations because
the list did not sort the same way.");
}
static class BrokenSorter
implements Comparator
{
@Override
public int compare(String a, String b)
{
if(a.equals("Miscellaneous"))
return 1;
return a.compareTo(b);
}
}
static class WorkingSorter
implements Comparator
{
@Override
public int compare(String a, String b)
{
if(a.equals("Miscellaneous"))
return 1;
if(b.equals("Miscellaneous"))
return -1;
return a.compareTo(b);
}
}
}
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlCcj7cACgkQ9CaO5/Lv0PBpawCeORBT62XWcjyw+SruT6Bhkh50
sDEAn1ZjSiPR70+DV/QVBFOjXKjH498o
=F3QS
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Components
No. I am curious about working of Tomcat so I am asking these core questions. that's all !! In my syllabus, no special subject or project related Tomcat, so from onwards question are from my curiosity point of view only; not any assignment or h/w!! Hope u all will understand and guide me !! -- Cheers, Mayur. From: Pid To: Tomcat Users List Sent: Friday, November 9, 2012 2:10 AM Subject: Re: Tomcat Components On 08/11/2012 17:06, Ram Laxman wrote: > Hi, > > I want to know what are components of Tomcat 7? > > As mentioned in wiki , tomcat 4 has Catalina,Coyote and Jasper components!!! > > But as I searched through the tomcat change notes I have observed several > others > > such as Cluster, Web Application but not getting fix no in this release !! > > Help !! > > -- > > CHEERS, > > MAYUR. Is this your homework? p -- [key:62590808]
Re: This is just plain ... odd.
On Thursday, November 08, 2012 07:36:20 PM Lyallex wrote: > The only difference between the two executions is the fact that the test > code executes in > it's own instance of the JVM whereas the other execution runs in an > instance shared with the container. > > I accept that the behaviour may be undefined even though it is consistently > repeatable in both environments > but surely given everything else being equal the results should be the same > ... or maybe I'm just losing the plot. No, you're right but just missing some small difference in the environments. I'd verify that you get the same input data in the same order in both cases, and that you're starting with the same size container and using the same sort, etc. Something is different, if it isn't the data then it has to be in the code. Last time I found something like this is was a replaced class caused by a classpath difference - maybe walk the debug and see exactly what is being executed in the sort? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Components
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ram, On 11/8/12 12:06 PM, Ram Laxman wrote: > I want to know what are components of Tomcat 7? Well, first you've got yourself a "T". That's the most important, which makes sense, because it's first one listed. Why wouldn't you put your best foot forward? And "T" is a really top-notch letter. Not like "I". "I" is a really bad choice when getting started. Sorry, Apple. After that, you have an "o". The crazy thing about that is that it doesn't sound like "O". No! It sounds like "ah". Mind = blown. And we're just at the second component of Tomcat at this point. I'm not sure you will be able to make it to the end without literally exploding with excitement. "m" is next and really starts building the intensity. You get to really mash your lips together -- maybe get a little tooth-tapping action goin' on, too. It also gives you the opportunity to pause and reflect on the great community Tomcat has surrounding it: all the volunteer programmers and people who post to the list. Those folks are great, and wasting their time would be ... a shame. "m" also gets used a lot in Muse's recent "Madness" single which ... kind of disappointed me. Alas, Origin of Symmetry is probably impossible to top so I'm glad they aren't even trying. We've arrived at "c". Lots of people hate the "c word" for some reason. I don't like cats themselves in general (there was one cat I really did like, but that one acted like a dog, so it wasn't really a cat except for the sneezing), but the word "cat" isn't a big deal for me. I don't understand what all the fuss is about. Now for the "a". Like the "o", this one doesn't really sound like "A" (like "ay" or "eh"). Alas! Instead, it sounds like .. hmm. Like the "a" in "grab". I think of "grab" because that's a very verby-sounding word. And Tomcat verbs things... verbs them very well. This is a great addition to Tomcat's architecture because it brings an element of mystique... it's tough to explain how to pronounce it, for instance. Now for the coup de grâce, and it's going to shatter your skull: another "t". This one is small... diminutive, even. Much less fuss than that /other/ "T" at the beginning, the one with all the excitement. This one is much more understated. Demure. Silent to some, who tend to skip the final consonant in such cases -- where it sounds more like Tomca'h than Tomcat. Then there's this weird "7". I think that's the version number. > As mentioned in wiki , tomcat 4 has Catalina,Coyote and Jasper > components!!! The later versions of Tomcat have fewer exclamation points. That must be why everyone prefers Tomcat 4. Little known fact: Tomcat's performance is inversely proportional to the number of exclamation marks used in sentences. So, every time you type one, Tomcat get slower. And God kills a lolcat. > But as I searched through the tomcat change notes I have observed > several others such as Cluster, Web Application but not getting fix > no in this release !! That will likely be fixed in Tomcat 8. Stay tuned. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCcOC4ACgkQ9CaO5/Lv0PBU/gCeNx9WflpOptJ28Fz68dhqQrXD 4msAnRtSG6w5CjfdhvVIZbBJeqTJ3hWB =PW9n -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form based login authentication
On Friday, November 09, 2012 01:02:55 AM Konstantin Kolinko wrote: > 1. When and how do you obtain the value for your jsessionid? Beware > that the session id is changing when you do authentication. That is > done to prevent session fixation attacks. The .jnlp would be generated on the fly after a login, so it would have the jsessionid just generated by the user authentication - if I can get through the login. But I'm not getting there as a successful login isn't redirected to the original target (or, perhaps, the jsessionid generated by the login isn't properly appended to the original url). > 2. It isn't timeout. > It means that you've got a new session, and so Tomcat does not know > where to redirect you after the login. > > See > response.sendError(HttpServletResponse.SC_REQUEST_TIMEOUT > call in o.a.c.authenticator.FormAuthenticator I landed in the login as a function of the authentication, so it seems that I should end up where I was originally trying to go after the authentication succeeds. Since the session has to be in the URL there should have been a URL rewrite for the new session performed after the login and session was created. This old thread seem applicable: http://tomcat.10.n6.nabble.com/AuthenticatorBase- setChangeSessionIdOnAuthentication-without-cookies-td4987045.html It's entirely possible (likely) that I'm missing something, but it sure looks like you can't get through a login.jsp with URL based session data. I'd be delighted to wrap this test case up in a .war, I was posting here to make sure that I wasn't completely missing some point. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: This is just plain ... odd.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lyallex, On 11/8/12 8:35 AM, Lyallex wrote: > I thought about posting this to a Java list but I can't reproduce > it 'standalone' so I thought I'd have a go here. There's something to that "can't reproduce it standalone" that you should be worried about. > I have a facade that publishes a method that contracts to return a > list of categories ordered alphabetically All problems in computer science can be solved by another layer of abstraction. Sure you can't fit a Proxy to a Service in there? > My facade calls out to a database server that returns a > List in random order. I then call collections.sort on the > list and return the result. > > [ ... ] > > If I test this by running a client of the facade I get the expected > results, the list is ordered as required with "Miscellaneous" on > the end > > However, and here's the thing, When my app starts an initialisation > servlet runs, calls the facade method and puts the resulting List > on the application context. When I render the list via a custom tag > the list has in some way been altered so that the String > "Miscellaneous" is in it's 'natural' position not what I want at > all. What does that "custom tag" do? A beer says it sorts something. Or, maybe you have some silly client-side process that sorts the entries after they are loaded into the browser. > I have tried everything I can think of to reproduce this behaviour > in a standalone Java program but the list is always returned as > required. When I call the method from a servlet the list is always > returned in it's natural order, I know collections.sort is being > executed as the list is in alpha order, it's almost as if the > comparator is being replaced in some way Are you using Collections.sort() or are you using a sorted collection? If you are calling Collections.sort() then the list is sorted once and it can be mutated. If you have a sorted list, then the comparator could conceivably be "replaced" (but really only by creating a new Collection). > I have no servlet filters or any other code 'in the way' between > the facade and the initialization servlet. Sounds like the problem is between the application scope and the page. Custom tag? Secondary sort? Simple test that doesn't require you to read any of your own code: Wrap the sorted collection in the application scope with Collections.unmodifiableList(sortedList). Now you'll get an exception with a stack trace whenever any code tries to re-sort it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCcNB4ACgkQ9CaO5/Lv0PDLuACgp/C8BkyI0cPOY5YoiwlJHnwe td0AniTAY+GDt1h1cI45Czj9VMqLuu7U =HvRr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL Certificate Help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian, On 11/8/12 4:39 AM, Brian Burch wrote: > On 07/11/12 21:13, Alissa Schneider wrote: >> * I recreated the keystore. > > Which will have generate a NEW public/private key pair. +1 >> * I imported the CA-signed certificate. > > But when did you generate the certificate request for this > certificate. Does it contain the SAME public key as in your new > keystore? Probably not. My guess is that the keystore in question isn't the one being used by Tomcat. Allison: please post your configuration plus the path of the keystore file you have been re-working. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCcLhgACgkQ9CaO5/Lv0PAKXQCgtRZF7YflGYGZ8BG9B2UAuATR 7vMAnijZ3OhV4ADd0Uks+3Gq5mMQQdBQ =0X0O -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: App Initialization Order In Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jose, On 11/7/12 8:30 PM, Jose H. Martinez wrote: > Thanks! This is indeed an interesting solution but I was looking > for something more "configurable". Does anybody know if there are > plans to add this functionality to Tomcat in the future? The alphabetical thing is *very* fragile. The better bet is to make your webapps tolerant of being brought-up in any order. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCcLXAACgkQ9CaO5/Lv0PDdzgCffTNjvPI/unodHGfds92zCL1W Jy4AoLjo4Gt2XoBTAdzHrn8g5PYNohpO =UDyW -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Logging of user's login attempts
On 11/8/2012 12:29 PM, Christopher Gross wrote:
Using Tomcat 6.0.36.
Realm:
Is there a way that I can set it up to do user login auditing, so
that I can see when a user logs in, or when they have a failed
attempt, etc? Been trying to google an answer, but I haven't been
finding anything useful or specific.
Let me know if there are any other config file snippets I can provide
to figure out what I need to change.
Thanks!
-- Chris
Chris,
Note, I haven't tried this so I may be completely off-base. The
following assumes that you're using the default JULI logging setup.
The realm classes are logged via Tomcat's JULI logging system (unless
you've converted to log4j). You'll need to add some logging for realms.
In $CATALINA_BASE/conf, there is a file called logging.properties.
You'll need to modify that in three places.
1. Add a new handler by appending it to the list of current handlers
Call it something like: 5realm.org.apache.juli.FileHandler
So your handlers line now looks like:
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler,
3manager.org.apache.juli.FileHandler,
4host-manager.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler,5realm.org.apache.juli.FileHandler
(sorry for the line wrapping)
2. Add the logging properties for your new handler
Underneath the host manager entry, add something like the following:
5realm.org.apache.juli.FileHandler.level = FINE
5realm.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
5realm.org.apache.juli.FileHandler.prefix = realm.
This sets up a realm log file in $CATALINA_BASE/logs.
3. Now set up the properties for the specific logger
In the Facilities section, add something like the following after the
host-manager entry.
org.apache.catalina.realm.MESSAGES.level = WARN
org.apache.catalina.realm.MESSAGES.handlers =
5realm.org.apache.juli.FileHandler
(again, sorry for the line wrapping)
The values on the left contain the package you want to log
(org.apache.catalina.realm in this case), the message level
(MESSAGES.level), and the handler (MESSAGES.handlers).
The values on the right contain the actual level (WARN, since from the
source code all login failures look like they are at the WARN level),
and the handler you defined above (5realm.org.apache.juli.FileHandler).
Restart Tomcat and you should see login failures in realm.[date].log,
where [date] is the date (rotated daily).
More information on configuring logging can be found here:
http://tomcat.apache.org/tomcat-6.0-doc/logging.html
Again, I've not done this for Realm logging. I've done this for Cluster
logging and it seems to work well.
. . . . just my two cents.
/mde/
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Form based login authentication
2012/11/8 Russ Kepler : > Using: > > Linux main 3.2.0-32 > Tomcat 7.0.32 > Java version "1.7.0_09" > (working through Eclipse Juno) > > I've been assigned what should have been a pretty simple task, a jnlp launcher > following a login to the web server. I've implemented what seemed to me to be > the simplest solution - form based login going through j_security_check, after > which I pass the jsessionid through a .jnlp built on the fly. This would pass 1. When and how do you obtain the value for your jsessionid? Beware that the session id is changing when you do authentication. That is done to prevent session fixation attacks. > the session to the Java Web Start and let me pass it as well to me > application. I was planning on having the application perform the login > manually if it isn't given a working session on startup. I'm not having a lot > of luck. > > I believe that I have the user login bit setup correct as I see the failed > login when I enter the incorrect login. When I enter a working name/password > pair I get a 408 - timeout. That goes away if I change web.xml: > > > 30 > URL > > > to the cookie form: > > > 30 > COOKIE > > > After that everything works as expected, so it appears that the 408 is related > to the URL tracking. I've tried this with the internal browser in Eclipse as > well as Firefox and get the same problem. I'm guessing the j_security_check > isn't redirecting with a rewritten URL and instead returns a timeout on a > successful login. > 2. It isn't timeout. It means that you've got a new session, and so Tomcat does not know where to redirect you after the login. See response.sendError(HttpServletResponse.SC_REQUEST_TIMEOUT call in o.a.c.authenticator.FormAuthenticator > If this is a known behaviour I have not been able to find anything after > spending a lot of time in google (more people seem to be trying to get rid of > the url rewrite), but since this is a new environment I may not have a grip of > the appropriate tags to be searching. > BTW, if you want to try running with a debugger, see https://wiki.apache.org/tomcat/FAQ/Developing#Debugging Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Specify order in which war files are deployed under tomcat
On 07/11/2012 21:32, Jose H. Martinez wrote: > Hello, > > I am running two applications under tomcat. One application is a web > service and the other is a web app that depends on the web service to be > started first before it can be initialized. The problem I am having is that > the web app is starting before the web service. Is there a way to tell > tomcat the order in which the war files should be deployed? > > Note: In the future we will deploy the applications on different servers > but for now that's not an option. > Use Tomcat 7.0.x and enable multi-threaded deployment, then one won't block and prevent the other from starting. p -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Handling requests when under load - ACCEPT and RST vs non-ACCEPT
On 08/11/2012 15:03, Asankha C. Perera wrote: > Hi Mark what happens if some other process grabs the port in the meantime: what is Tomcat supposed to do then? >>> In reality I do not know of a single client production deployment that >>> would allocate the same port to possibly conflicting services, that may >>> grab another's port when its suffering under load. >> Just because it wouldn't cause a problem for a limited subset of Tomcat >> users - your clients - does not mean that it would not cause problems >> for other Tomcat users. >>> I cannot see any other issues of turning off accepting - and I am >>> curious to know if anyone else could share their views on this - >>> considering real production deployments >> The problems have already been explained to you. Another process could >> use the port. > I would consider such production deployment as a risk - a Tomcat crash, > or even a restart might end up in a soup if another process starts using > the port in the mean time.. It is not uncommon for monitoring tools to attempt to (re)start a service when it is observed not to be listening on its designated port. p >> Having reviewed this thread the problem you seem to be trying to solve >> is this: >> - a load-balancer is in use >> - Tomcat is under load >> - a client attempts a connection >> - the connection is added to the TCP backlog >> - Tomcat does not process the connection before it times out >> - the connection is reset when it times out >> - the client can't differentiate between the above and when an error >> occurs during processing resulting in a connection reset >> - the client doesn't know whether to replay the request or not > Yes, this is correct >> First of all, it is extremely rare for Tomcat to reset a connection once >> processing has started. The only circumstances where I am aware that >> would happen is if Tomcat is shutting down and a long running request >> failed to complete or if Tomcat crashes. All other error cases should >> receive an appropriate HTTP error code. In a controlled shut down load >> can be moved off the Tomcat node before it is shut down. That leaves >> differentiating a Tomcat crash during request processing and the request >> timing out in the backlog. >> For GET requests this should be a non-issue since GET requests are meant >> to be idmepotent. GET requests can always be re-tried after a TCP reset. >> >> For POST requests, use of the 100 Continue status can enable the client >> to determine if the headers have been received. A TCP reset before the >> 100 continue response means the request needs to be re-tried. A TCP >> reset after the 100 continue response means it is unknown if a retry is >> necessary (there is no way for the client to determine the correct >> answer in this case). >> >> Given the above I don't see any reason to change Tomcat's current >> behaviour. > Ok, thank you for considering my proposal. I respect the decision of the > Tomcat community. > > Hopefully someone else will find this thread useful in future to > understand the issue better and to overcome it > > regards > asankha > -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: Tomcat Components
On 08/11/2012 17:06, Ram Laxman wrote: > Hi, > > I want to know what are components of Tomcat 7? > > As mentioned in wiki , tomcat 4 has Catalina,Coyote and Jasper components!!! > > But as I searched through the tomcat change notes I have observed several > others > > such as Cluster, Web Application but not getting fix no in this release !! > > Help !! > > -- > > CHEERS, > > MAYUR. Is this your homework? p -- [key:62590808] signature.asc Description: OpenPGP digital signature
Logging of user's login attempts
Using Tomcat 6.0.36. Realm: Is there a way that I can set it up to do user login auditing, so that I can see when a user logs in, or when they have a failed attempt, etc? Been trying to google an answer, but I haven't been finding anything useful or specific. Let me know if there are any other config file snippets I can provide to figure out what I need to change. Thanks! -- Chris
Re: Stress test on tomcat
Luciano Andress Martini wrote: Hi friend sorry if i am repeating same topic, but actually what is the better thing to do a stress test on tomcat6. You are probably not getting an answer, because it is a rather stupid question. Hint : what do you want to test or check or measure ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Stress test on tomcat
Hi friend sorry if i am repeating same topic, but actually what is the better thing to do a stress test on tomcat6. Thanks ! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: This is just plain ... odd.
> [snip] > > You got the same (wrongish) results since you gave the sort the same order > in > the list. I can't recall how merge sort can freak out when given > conflicting > compares, I seem to recall that you might get an endless loop under some > circumstances as it orders and reorders the same group of objects. > This is all very interesting, no really it is, but it doesn't really answer the original question which is that given the same initial data in the same initial order and executing exactly the same code in the same release of Java produces different results. The only difference between the two executions is the fact that the test code executes in it's own instance of the JVM whereas the other execution runs in an instance shared with the container. I accept that the behaviour may be undefined even though it is consistently repeatable in both environments but surely given everything else being equal the results should be the same ... or maybe I'm just losing the plot. Lyallex
Tomcat Components
Hi, I want to know what are components of Tomcat 7? As mentioned in wiki , tomcat 4 has Catalina,Coyote and Jasper components!!! But as I searched through the tomcat change notes I have observed several others such as Cluster, Web Application but not getting fix no in this release !! Help !! -- CHEERS, MAYUR.
Re: This is just plain ... odd.
On Thursday, November 08, 2012 10:05:43 AM djohn...@desknetinc.com wrote:
>
> This is closer, but still doesn't work correctly if two "Misc" categories
> are being compared, or one "Misc" category is compared to itself.
> Try:
>
> @Override
> public int compareTo(Category c) {
> if(category.equals("Miscellaneous")) {
> if(category.equals(c.category) return 0; // correctly
> handle equality.
> else return 1;
> } elseif (c.category.equals("Miscellaneous")) {
> return -1;
> } else {
> return category.compareTo(c.category);
> }
> }
You're right for the general case of compare(), but in my defense I'd like to
say that merge sort will never compare the same object and the list was
constrained to one special object, so in this case it'd work for the sort.
But it's likely better to handle the general case "just in case" someone other
than the sort uses the compare() so your comment is well taken. Nothing like
fixing up one bad behaviour only to replace it with some more obscure one.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: This is just plain ... odd.
On Thursday, November 08, 2012 03:06:51 PM Lyallex wrote: > > I'm not sure that you can ever get consistent results if the input order > > is > > random. > > Well perhaps 'random' was a bit 'random' the select returns the data in the > same order it was entered, ordered by id. > Not necessarily the same as alpha as I'm sure you appreciate. the fact is > that the data was always returned in the same order > by the database, just not the order I wanted. This is why I was > particularly confused. > > Whatever, your code works, now I just gotta figure out why Because you were only handling one end of the compare against the special object. Since the special object could appear as the object to be compared against as well as the object performing the compare the merge sort was being given conflicting comparisons against the special object - always the greatest when the special was performing the compare and alphabetically(ish) when it was the object given to the compare method. You got the same (wrongish) results since you gave the sort the same order in the list. I can't recall how merge sort can freak out when given conflicting compares, I seem to recall that you might get an endless loop under some circumstances as it orders and reorders the same group of objects. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Form based login authentication
Using: Linux main 3.2.0-32 Tomcat 7.0.32 Java version "1.7.0_09" (working through Eclipse Juno) I've been assigned what should have been a pretty simple task, a jnlp launcher following a login to the web server. I've implemented what seemed to me to be the simplest solution - form based login going through j_security_check, after which I pass the jsessionid through a .jnlp built on the fly. This would pass the session to the Java Web Start and let me pass it as well to me application. I was planning on having the application perform the login manually if it isn't given a working session on startup. I'm not having a lot of luck. I believe that I have the user login bit setup correct as I see the failed login when I enter the incorrect login. When I enter a working name/password pair I get a 408 - timeout. That goes away if I change web.xml: 30 URL to the cookie form: 30 COOKIE After that everything works as expected, so it appears that the 408 is related to the URL tracking. I've tried this with the internal browser in Eclipse as well as Firefox and get the same problem. I'm guessing the j_security_check isn't redirecting with a rewritten URL and instead returns a timeout on a successful login. If this is a known behaviour I have not been able to find anything after spending a lot of time in google (more people seem to be trying to get rid of the url rewrite), but since this is a new environment I may not have a grip of the appropriate tags to be searching. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: This is just plain ... odd.
> I'm not sure that you can ever get consistent results if the input order is > random. Well perhaps 'random' was a bit 'random' the select returns the data in the same order it was entered, ordered by id. Not necessarily the same as alpha as I'm sure you appreciate. the fact is that the data was always returned in the same order by the database, just not the order I wanted. This is why I was particularly confused. Whatever, your code works, now I just gotta figure out why Thanks Lyallex
Re: This is just plain ... odd.
Russ Kepler wrote on 11/08/2012 09:22:41 AM:
> From: Russ Kepler
> To: Tomcat Users List ,
> Date: 11/08/2012 09:23 AM
> Subject: Re: This is just plain ... odd.
>
> On Thursday, November 08, 2012 01:35:55 PM Lyallex wrote:
> > I have tried everything I can think of to reproduce this behaviour
> > in a standalone Java program but the list is always returned
> > as required. When I call the method from a servlet the list is always
> > returned
> > in it's natural order, I know collections.sort is being executed as
> > the list is in alpha order, it's almost as if the comparator is being
> > replaced in some way
> >
> > I have no servlet filters or any other code 'in the way' between the
facade
> > and the initialization servlet.
> >
> > Any ideas ?
> I'm not sure that you can ever get consistent results if the input order
is
> random. The Collections.sort() implements a merge sort and the merge
sort
> depends on a consistent result from the compare() method. As
implemented the
> compare() will return what you want when the object being compared
against is
> the "Misc" object but return a string compare when it isn't. Try this:
> @Override
> public int compareTo(Category c) {
> if(category.equals("Miscellaneous")){
> return 1;
> } elseif (c.category.equals("Miscellaneous")) {
> return -1;
> else{
> return category.compareTo(c.category);
> }
> }
> (side comment: If the list is a decent size it might make sense to
compare
> against the Misc object rather than compare all strings but it's likely
not
> worth the bother).
> The was I usually handle this is to .remove the offending object
> from the list,
> sort, then .add it back on after the sort. Keep the odd code local to
the
> oddity.
This is closer, but still doesn't work correctly if two "Misc" categories
are being compared, or one "Misc" category is compared to itself.
Try:
@Override
public int compareTo(Category c) {
if(category.equals("Miscellaneous")) {
if(category.equals(c.category) return 0; // correctly
handle equality.
else return 1;
} elseif (c.category.equals("Miscellaneous")) {
return -1;
} else {
return category.compareTo(c.category);
}
}
---
David S. Johnson
DeskNet Inc.
Re: Handling requests when under load - ACCEPT and RST vs non-ACCEPT
Hi Mark what happens if some other process grabs the port in the meantime: what is Tomcat supposed to do then? In reality I do not know of a single client production deployment that would allocate the same port to possibly conflicting services, that may grab another's port when its suffering under load. Just because it wouldn't cause a problem for a limited subset of Tomcat users - your clients - does not mean that it would not cause problems for other Tomcat users. I cannot see any other issues of turning off accepting - and I am curious to know if anyone else could share their views on this - considering real production deployments The problems have already been explained to you. Another process could use the port. I would consider such production deployment as a risk - a Tomcat crash, or even a restart might end up in a soup if another process starts using the port in the mean time.. Having reviewed this thread the problem you seem to be trying to solve is this: - a load-balancer is in use - Tomcat is under load - a client attempts a connection - the connection is added to the TCP backlog - Tomcat does not process the connection before it times out - the connection is reset when it times out - the client can't differentiate between the above and when an error occurs during processing resulting in a connection reset - the client doesn't know whether to replay the request or not Yes, this is correct First of all, it is extremely rare for Tomcat to reset a connection once processing has started. The only circumstances where I am aware that would happen is if Tomcat is shutting down and a long running request failed to complete or if Tomcat crashes. All other error cases should receive an appropriate HTTP error code. In a controlled shut down load can be moved off the Tomcat node before it is shut down. That leaves differentiating a Tomcat crash during request processing and the request timing out in the backlog. For GET requests this should be a non-issue since GET requests are meant to be idmepotent. GET requests can always be re-tried after a TCP reset. For POST requests, use of the 100 Continue status can enable the client to determine if the headers have been received. A TCP reset before the 100 continue response means the request needs to be re-tried. A TCP reset after the 100 continue response means it is unknown if a retry is necessary (there is no way for the client to determine the correct answer in this case). Given the above I don't see any reason to change Tomcat's current behaviour. Ok, thank you for considering my proposal. I respect the decision of the Tomcat community. Hopefully someone else will find this thread useful in future to understand the issue better and to overcome it regards asankha -- Asankha C. Perera AdroitLogic,http://adroitlogic.org http://esbmagic.blogspot.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: This is just plain ... odd.
On Thursday, November 08, 2012 01:35:55 PM Lyallex wrote:
> I have tried everything I can think of to reproduce this behaviour
> in a standalone Java program but the list is always returned
> as required. When I call the method from a servlet the list is always
> returned
> in it's natural order, I know collections.sort is being executed as
> the list is in alpha order, it's almost as if the comparator is being
> replaced in some way
>
> I have no servlet filters or any other code 'in the way' between the facade
> and the initialization servlet.
>
> Any ideas ?
I'm not sure that you can ever get consistent results if the input order is
random. The Collections.sort() implements a merge sort and the merge sort
depends on a consistent result from the compare() method. As implemented the
compare() will return what you want when the object being compared against is
the "Misc" object but return a string compare when it isn't. Try this:
@Override
public int compareTo(Category c) {
if(category.equals("Miscellaneous")){
return 1;
} elseif (c.category.equals("Miscellaneous")) {
return -1;
else{
return category.compareTo(c.category);
}
}
(side comment: If the list is a decent size it might make sense to compare
against the Misc object rather than compare all strings but it's likely not
worth the bother).
The was I usually handle this is to .remove the offending object from the list,
sort, then .add it back on after the sort. Keep the odd code local to the
oddity.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
This is just plain ... odd.
Java 1.6
Tomcat 6.0.35
Ubuntu Linux 12.04
I thought about posting this to a Java list but I can't
reproduce it 'standalone' so I thought I'd have a go here.
It's quite long and involved...
I have a web application that lists items for sale by category
I have a facade that publishes a method that contracts to return
a list of categories ordered alphabetically
The category 'Miscellaneous' is required to be appended to the end of the
list.
My facade calls out to a database server that returns a List
in random order. I then call collections.sort on the list and return the
result.
I've been messing around with various things and I have come up against a
very
strange problem.
One way of satisfying the contract is to write the Category class as follows
I'm not suggesting this is in any way acceptable industrial strength
code, I'm doing it to illustrate a point.
public class Category implements Comparable{
private Integer categoryId = 0;
private String category = "";
@Override
public int compareTo(Category c) {
if(category.equals("Miscellaneous")){
return 1;
}
else{
return category.compareTo(c.category);
}
}
etc
If I test this by running a client of the facade
I get the expected results, the list is ordered as required with
"Miscellaneous" on the end
However, and here's the thing, When my app starts
an initialisation servlet runs, calls the facade method
and puts the resulting List on the application context.
When I render the list via a custom tag the list has
in some way been altered so that the String
"Miscellaneous" is in it's 'natural' position
not what I want at all.
I have tried everything I can think of to reproduce this behaviour
in a standalone Java program but the list is always returned
as required. When I call the method from a servlet the list is always
returned
in it's natural order, I know collections.sort is being executed as
the list is in alpha order, it's almost as if the comparator is being
replaced in some way
I have no servlet filters or any other code 'in the way' between the facade
and the initialization servlet.
Any ideas ?
TIA
Lyallex
Re: SSL Certificate Help
Alissa, On 7.11.2012 22:13, Alissa Schneider wrote: Here are the steps I have taken thus far: * I deleted my original keystore that held my self-signed certificate. * I deleted the self-signed certificate. * I recreated the keystore. * I imported the CA-signed certificate. * I have an index.txt file that I deleted all the contents from so it is empty. * The server.xml file reflects the current keystore/pw information and the SSL lines have been uncommented. Still, when I visit https://localhost:8443, the browser throws a certificate warning. When I click on the certificate warning and view certificate, it displays information on my self-signed certificate (that I've deleted). I think if I could figure out how to make Tomcat point to the CA certificate instead of the old one, this would work for me. However, I'm not sure how to clear the Tomcat "cache" so to speak. Are you sure that the warning is the same? Perhaps the first warning was about certificate not being signed by CA, and second warning is about something else? Every (CA-signed or self-signed) certificate is issued for the specific hostname. If certificate hostname does not match hostname from browser URL, browser will issue a warning. Maybe that is the case here. If your CA-signed certificate is bound to hostname other than "localhost" and you access your Tomcat server using browser URL "https://localhost:8443";, than the browser will issue a warning. I believe not a single CA would sign certificate for loopback interface hostname "localhost", only for FQDN like "server.example.com". Therefore, you should access your server using FQDN which your certificate is issued for. -Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Handling requests when under load - ACCEPT and RST vs non-ACCEPT
On 08/11/2012 03:35, Asankha C. Perera wrote: > Hi Esmond >> Closing the listening socket, as you seem to be now suggesting, is a >> very poor idea indeed: > I personally do not think there is anything at all bad about turning it > off. After all, if you are not ready to accept more, you should be clear > and upfront about it, even at the TCP level. Having different thresholds > to stop listening (say at 4K), and to resume (say at 2K) would ensure > that you do not start acting weirdly by starting/stopping/starting/.. > acceptance around just one value. >> what happens if some other process grabs the port in the meantime: >> what is Tomcat supposed to do then? > In reality I do not know of a single client production deployment that > would allocate the same port to possibly conflicting services, that may > grab another's port when its suffering under load. Just because it wouldn't cause a problem for a limited subset of Tomcat users - your clients - does not mean that it would not cause problems for other Tomcat users. > I cannot see any other issues of turning off accepting - and I am > curious to know if anyone else could share their views on this - > considering real production deployments The problems have already been explained to you. Another process could use the port. Having reviewed this thread the problem you seem to be trying to solve is this: - a load-balancer is in use - Tomcat is under load - a client attempts a connection - the connection is added to the TCP backlog - Tomcat does not process the connection before it times out - the connection is reset when it times out - the client can't differentiate between the above and when an error occurs during processing resulting in a connection reset - the client doesn't know whether to replay the request or not First of all, it is extremely rare for Tomcat to reset a connection once processing has started. The only circumstances where I am aware that would happen is if Tomcat is shutting down and a long running request failed to complete or if Tomcat crashes. All other error cases should receive an appropriate HTTP error code. In a controlled shut down load can be moved off the Tomcat node before it is shut down. That leaves differentiating a Tomcat crash during request processing and the request timing out in the backlog. For GET requests this should be a non-issue since GET requests are meant to be idmepotent. GET requests can always be re-tried after a TCP reset. For POST requests, use of the 100 Continue status can enable the client to determine if the headers have been received. A TCP reset before the 100 continue response means the request needs to be re-tried. A TCP reset after the 100 continue response means it is unknown if a retry is necessary (there is no way for the client to determine the correct answer in this case). Given the above I don't see any reason to change Tomcat's current behaviour. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL Certificate Help
On 07/11/12 21:13, Alissa Schneider wrote: Hi - I'm a novice Tomcat user. I've only used the tool to support BusinessObjects. I recently was asked to set up SSL for the first time. Initially I created my own self-signed certificate and was able to get everything working fine, although I would get the 'certificate warning' error message when going to https://localhost:8443, but this was expected. Then my IT admin gave me a CA-signed certificate to use instead so we wouldn't get that warning. The problem I am having, is that Tomcat still seems to be reading my old self-signed certificate instead of being pointed to the CA-signed certificate. Here are my environment specifics: * Windows 2008 R2 64-bit * Tomcat 6.0.24 * IE 8 Here are the steps I have taken thus far: * I deleted my original keystore that held my self-signed certificate. * I deleted the self-signed certificate. * I recreated the keystore. Which will have generate a NEW public/private key pair. * I imported the CA-signed certificate. But when did you generate the certificate request for this certificate. Does it contain the SAME public key as in your new keystore? * I have an index.txt file that I deleted all the contents from so it is empty. * The server.xml file reflects the current keystore/pw information and the SSL lines have been uncommented. Still, when I visit https://localhost:8443, the browser throws a certificate warning. When I click on the certificate warning and view certificate, it displays information on my self-signed certificate (that I've deleted). I think if I could figure out how to make Tomcat point to the CA certificate instead of the old one, this would work for me. However, I'm not sure how to clear the Tomcat "cache" so to speak. I appreciate any help! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: AW: Problem WAR-file-deployment tomcat 6.0.36
Hi, we had an error in the call of the anttask for the creation of the warfile. the webxml parameter was set with the Folder, where the web.xml is in not the web.xml itself. This results not in an error but in the creation of Folder web.xml in the warfile. Greetings, Meik Suchlich -Ursprüngliche Nachricht- Von: Mark Thomas [mailto:ma...@apache.org] Gesendet: Donnerstag, 8. November 2012 10:12 An: Tomcat Users List Betreff: Re: AW: Problem WAR-file-deployment tomcat 6.0.36 On 08/11/2012 08:22, Meik Suchlich wrote: > Hi, > > that seems to be the cause. I check, why there is this empty folder which > should not be created. > But it works with tomcat-6.0.35. Why does this error not occur in the > previous Version. > Is it because of the bugfix ? Yes. This looks like [1] as listed in [2]. Mark [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=53531 [2] http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Problem WAR-file-deployment tomcat 6.0.36
On 08/11/2012 08:22, Meik Suchlich wrote: > Hi, > > that seems to be the cause. I check, why there is this empty folder which > should not be created. > But it works with tomcat-6.0.35. Why does this error not occur in the > previous Version. > Is it because of the bugfix ? Yes. This looks like [1] as listed in [2]. Mark [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=53531 [2] http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Problem WAR-file-deployment tomcat 6.0.36
Hi, that seems to be the cause. I check, why there is this empty folder which should not be created. But it works with tomcat-6.0.35. Why does this error not occur in the previous Version. Is it because of the bugfix ? Thanks, Meik -Ursprüngliche Nachricht- Von: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Gesendet: Donnerstag, 8. November 2012 09:16 An: Tomcat Users List Betreff: Re: Problem WAR-file-deployment tomcat 6.0.36 2012/11/8 Meik Suchlich : > Hi, > > I just changed the tomcat from 6.0.35 to 6.0.36, by simply changing the > symlink from the apache-6.0.35 to the apache 6.0.36-folder and cleaning > work-directory. > After that the deployment of warfiles fails with following Exception: > > Nov 08, 2012 6:38:50 AM org.apache.catalina.startup.ContextConfig init > SEVERE: Exception fixing docBase for context [/testapp] > java.io.IOException: Unable to create the directory > [/data/tomcat/webapps/testapp/WEB-INF/web.xml] >at > org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:168) It sounds as if your war file contains a directory "web.xml/" as well as a web.xml file. You cannot create a directory when a file with the same name already exists. You can use "jar -t" to list the files contained in your archive. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem WAR-file-deployment tomcat 6.0.36
2012/11/8 Meik Suchlich : > Hi, > > I just changed the tomcat from 6.0.35 to 6.0.36, by simply changing the > symlink from the apache-6.0.35 to the apache 6.0.36-folder and cleaning > work-directory. > After that the deployment of warfiles fails with following Exception: > > Nov 08, 2012 6:38:50 AM org.apache.catalina.startup.ContextConfig init > SEVERE: Exception fixing docBase for context [/testapp] > java.io.IOException: Unable to create the directory > [/data/tomcat/webapps/testapp/WEB-INF/web.xml] >at org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:168) It sounds as if your war file contains a directory "web.xml/" as well as a web.xml file. You cannot create a directory when a file with the same name already exists. You can use "jar -t" to list the files contained in your archive. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
