Re: Question about tomcat startup ConcurrentModificationException
Hello Jilles So I have downloaded the mx4j-2.1.1.tar and untarred it, but since there is no exact match for jmx.jar in the mx4j distribution I zipinfo'd and sorted: the original tomcat/bin/jmx.tar (235 classes) mx4j.jar (285 classes) When diff'd, mostly a good match, but a couple of classes that are in jmx.jar are missing from mx4j.jar. I presume these are classes req'd by others in the package but are not called directly by tomcat. So you are suggesting that I replace the tomcat/bin/jmx.jar with the mx4j.jar ? If so, then I have a stupid question: when I do this replacement, should I rename the mx4j.jar to jmx.jar ? Maurice Jilles van Gurp wrote: The fix is to replace the mx4j jar file in the release (bin/jmx.jar) with the fixed version (latest 2.1.x) which has been available for a long time now from the mx4j project site. You might also search this mailinglist. This must be one of the more frequently raised topics. I know I found the right answer here half a year ago or so. I'd really appreciate a stable 5.0.x release with the fix. I've known about this bug for more than half a year now and I still encounter it at least once a week at customers. I then need to explain that it is not our product that is broken but tomcat and that it's a well known issue and it is easy to fix. Basically all our customers run into this issue. Lets face it, 5.0.28 is basically broken because of this easy to fix bug. People claim it rarely occurs (and consequently that it is perfectly acceptable to occasionally fail to launch with an obscure exception). Yet, I can't launch my webapp on an unpatched tomcat 5.0.28 unless I fix this first. Sometimes I forget on a clean install and then seconds later slap my forward. Just do a 5.0.28_01 with the fixed jar or finally move 5.0.30 to a stable release (I can't convince customers to install beta software) but please fix it one way or the other. Jilles Tim Funk wrote: Search bugzilla. There is a bug report about ConcurrentModificationException - it has to do with mx4j having a race condition. The bug describes a fix. -Tim Maurice Yarrow wrote: Hello Tomcat people When tomcat is restarted, it occasionally (1 in 25 times) gets the below exception. (tomcat 5.0.28, on Fedora Core 1) What is the significance of this? Thanks Maurice INFO: Starting Coyote HTTP/1.1 on http-8080 Sep 26, 2005 9:29:19 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8443 Sep 26, 2005 9:29:19 AM org.apache.coyote.tomcat5.MapperListener init WARNING: Error registering contexts java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782) at java.util.HashMap$EntryIterator.next(HashMap.java:824) at java.util.HashMap.putAllForCreate(HashMap.java:424) at java.util.HashMap.clone(HashMap.java:656) at mx4j.server.DefaultMBeanRepository.clone(DefaultMBeanRepository.java:56) at mx4j.server.MBeanServerImpl.findMBeansByPattern(MBeanServerImpl.java:160 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question about tomcat startup ConcurrentModificationException
Hello Tomcat people When tomcat is restarted, it occasionally (1 in 25 times) gets the below exception. (tomcat 5.0.28, on Fedora Core 1) What is the significance of this? Thanks Maurice INFO: Starting Coyote HTTP/1.1 on http-8080 Sep 26, 2005 9:29:19 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8443 Sep 26, 2005 9:29:19 AM org.apache.coyote.tomcat5.MapperListener init WARNING: Error registering contexts java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782) at java.util.HashMap$EntryIterator.next(HashMap.java:824) at java.util.HashMap.putAllForCreate(HashMap.java:424) at java.util.HashMap.clone(HashMap.java:656) at mx4j.server.DefaultMBeanRepository.clone(DefaultMBeanRepository.java:56) at mx4j.server.MBeanServerImpl.findMBeansByPattern(MBeanServerImpl.java:1603) at mx4j.server.MBeanServerImpl.queryObjectNames(MBeanServerImpl.java:1568) at mx4j.server.MBeanServerImpl.queryMBeans(MBeanServerImpl.java:1512) at org.apache.coyote.tomcat5.MapperListener.init(MapperListener.java:115) at org.apache.coyote.tomcat5.CoyoteConnector.start(CoyoteConnector.java:1537) at org.apache.catalina.core.StandardService.start(StandardService.java:489) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2313) at org.apache.catalina.startup.Catalina.start(Catalina.java:556) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:287) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Synchronize wrapper for session obj attrib get/set
Leon, Chuck: Thankyou very much for (1) pointing out that tomcat has internal session obj accesses, so go with something that accomplishes a global fix and (2) just as important: what the current patches are for 5.0.19+. Leon, I went with your pre-compiled StandardSession.class and replaced the original one in the catalina.jar and am up and running. Thanks again, gentlemen. Maurice Yarrow Leon Rosenberg wrote: Possibly the easiest thing to do is edit the StandardSession.java file and change the type of the attributes field to HashTable rather than HashMap, then rebuild the associated jar. The places that already synchronize on attributes can be left alone, since redundant synchs are allowed and have minimal performance impact. - Chuck Or, you take one of existing patches, see also: http://www.niallp.pwp.blueyonder.co.uk/TomcatBug36541.html or, you just get the last StandartSession version out of CVS ( sorry SVN since this weekend) , and compile it. regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Synchronize wrapper for session obj attrib get/set
Hello Tomcat people
For those not wishing to migrate at this time to 5.5.12
(in our case, from 5.0.28 and jdk 1.4) would the following
be sufficient for preventing deadlock access of the session
objects ?
In a given servlet, say, ServletA, for example, might have:
HttpSession session = getSessionCheckValid( request );
synchronized( session ) {
session.setAttribute( particularAttribName,
particularAttribVal );
}
The question arises, if this session obj is being used from
a variety of such servlets, does the above code in ServletA
prevent simultaneous access to the set method of the same obj
in a similar synchronized block in some other servlet, say,
in ServletB ?
If, on the other hand, one chooses to write a class extending
the HttpSession interface, and then (2) wrap the get/set and other
applicable methods with synchonized methods, then what is the
minimum amount of threading machinery that must to be provided
(i.e., Runnable, run(), etc) to accomplish this wrapping ?
For that matter, has someone done this who would be willing
to share such code ?
Maurice Yarrow
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to share static content across applications
Hello Tim
Saw your posting on the tomcat user's list.
I have a question about your response:
So how do you access the static resources, i.e.,
images, from the other two web apps?
This is what I tried and it does not work:
I created a separate webapp context with images,
and placed into tomcat/conf/Catalina/localhost
a element that looks like this:
and in webapps/img I
ln -s /usr/scratch/images images
to create the symlink. So far, so good
Then, for the web app which needed the images,
I created this element:
Then from one of the servlets in getimg, I tried to
try {
RequestDispatcher dispatcher =
getServletContext().getContext("/img").getRequestDispatcher("/images"+request.getPathInfo());
dispatcher.include(request, response);
} catch(Exception ex) {
ex.printStackTrace();
}
and to invoke as getimg/ImageServlet/subPath...
but nothing happened, and in fact, the
getServletContext().getContext("/img") returned null.
Note that the thusly constructed path to the image is
in fact correct. This was not an issue of Not Found.
Thanks
Maurice Yarrow
> I typically create a 3rd webapp with those shared images and other
> similar assets.
>
> Otherwise - you can import those shared assets into your webapp at
> build time by placing all the shared assets into their own version
> control repository.
>
> -Tim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: no luck with allowLinking="true"
Hello Hassan Thanks again: however: (1) tomcat is started by root who superusers tomcat process to be owned by user tomcat, as you can see from ps: 1415 tomcat /opt/j2sdk1.4.2_05/bin/java -Djava.endorsed.dirs=/opt/tomcat/comm,etc... (2) Tomcat owns the link: lrwxrwxrwx 1 tomcat tomcat 32 Sep 12 11:32 images -> /usr/scratch/images so tomcat certainly owns the link, but also: (3) Tomcat can write to and read from the linked dir directly: [EMAIL PROTECTED] webapps]$ ls -ld /usr/scratch/images drwxrwxr-x 2 tomcat tomcat 4096 Sep 12 11:44 /usr/scratch/images [EMAIL PROTECTED] webapps]$ echo hello > /usr/scratch/images/hello.dat (i.e., user tomcat has no problem creating only images dir) and [EMAIL PROTECTED] webapps]$ cat /usr/scratch/images/hello.dat hello (i.e., user tomcat has no problem seeing the file) and (4) also, tomcat can even delete the file via the link (no error, and file is removed) Maurice Hassan Schroeder wrote: Maurice Yarrow wrote: Neither configuration worked to allow symlinks. Also, as I indicated in my first letter, I even set up a completely new 5.0.30 complete deployment to test this issue, but the results were the same. That's good, eliminating as many variables as possible. And if that setup doesn't work... Is it possible you have a permissions problem between the Tomcat process userid and the owner of the linked directory? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: no luck with allowLinking="true"
Hassan Thank you for thinking about this and suggesting the context fragment that you have successfully used. I had tried such a fragment a little while back, without success, but tried it again just now exactly as you had indicated. I tried placing it in tomcat/conf/Catalina/localhost/getimg.xml and I also, separately, tried placing that Context element in the Host element of server.xml. Neither configuration worked to allow symlinks. Note: I know that the Context element works for me in the more broad usage of deploying a webapp in an arbitrary location: I just (again) tried /getimg/images and see the contents of that directory once the symlink is created. It's just that the getimg app itself still cannot see it. And, as I previously indicated, actually creating a directory in the webapp tree with images in it of course makes those images visible to the app. Thanks again for the suggestion. Frankly, I'm as confounded as you about this. As I indicated in my first letter, I always find (eventually) the correct configuration for just about anything that is required, but this has eluded me. There must be some conflict which I am not seeing, but, pretty much, my tomcat configuration is fairly vanilla: have postgres, am using OpenEJB as well as JDBC, all successfully. Use lots of XStream xml files for app information, but none of this should be a conflict. Hmmm, let's see: am also using the SSL/https Connector in the conf/server.xml, and have enabled CGI from the conf/web.xml, and all this works fine for me. Also, as I indicated in my first letter, I even set up a completely new 5.0.30 complete deployment to test this issue, but the results were the same. Puzzled, in Sunnyvale, Maurice Hassan Schroeder wrote: Maurice Yarrow wrote: I have simply had no success getting allowLinking="true". / Am running 5.0.28 (tried it in 5.0.30, as well, with same lack of success). / Shouldn't that just be: :: ? which works for me in TC 5.5.x, at least, and appears to match the Context attribute descriptions for 5.0.x in <http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/context.html> FWIW! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: no luck with allowLinking="true"
Darek Thanks for taking the time to look this over. I tried again, as you suggested. I did a search for any extraneous context fragment files that might conflict somehow: ls | while read dir;do echo = $dir; find $dir -name \*xml \ -exec grep -i ' element) does indeed work to point the webapp getimg to any directory in which I put the getimg tree, so that is not a problem. I know from previous experience that just about any time something doesn't work as it's supposed to, then I am making some configuration error. That guiding rule leads me to try virtually every possible combination of setups until what I am trying to do works - it's brutal, but effective. I am also very thorough in my research of available documentation. In this particular case, this is actually the third pass I am making at getting symlinks to work. And so, of course, I am pretty surprised that whatever it is that I am doing wrong has eluded my efforts so far. If it is of any help, I could additionally send any other configuration setups that might be related. Thanks again. Maurice Darek Czarkowski wrote: On Sun, 11 Sep 2005 16:55:38 -0700 Maurice Yarrow <[EMAIL PROTECTED]> wrote: Hello tomcat-users I have simply had no success getting allowLinking="true". I have read simply dozens and dozens of links with a standard recipe for doing this, as well as the tomcat documentation, of course. Am running 5.0.28 (tried it in 5.0.30, as well, with same lack of success). I have tried placing the context fragment (which, as a separate file, I call getimg.xml) in virtually every place I could think of, as well as the recommended locations: tomcat/conf/Catalina/localhost/getimg.xml In the server.xml element (at the bottom of the element) In the webapps directory... This is the context fragment I am using: I then place the following symbolic link in the webapps/getimg directory: ln -s /usr/scratch/images images and reboot tomcat. But, no visibility whatsoever! Of course, when I actually mkdir a directory in webapps/getimg, files in this directory are visible, but not with a symlink, and of course I don't want to have to actually put gigabytes of stuff in the tomcat tree. I have, however, successfully used the context element to point tomcat to my getimg webapp when I have located it outside of the tomcat/webapp directory (for example, with docbase="/tmp/getimg" or docbase="/usr/scratch/getimg") but tomcat and the webapp still cannot see the linked-in subdirectory at all. Pull-eesse help!!! Pleease!! Maurice Yarrow - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Try again, make sure you have only one declaration of context, since you could be overriding the declaration by including the incorrect one. Also make sure that user used to run tomcat has read access to the directory you created. DarekC - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
no luck with allowLinking="true"
Hello tomcat-users I have simply had no success getting allowLinking="true". I have read simply dozens and dozens of links with a standard recipe for doing this, as well as the tomcat documentation, of course. Am running 5.0.28 (tried it in 5.0.30, as well, with same lack of success). I have tried placing the context fragment (which, as a separate file, I call getimg.xml) in virtually every place I could think of, as well as the recommended locations: tomcat/conf/Catalina/localhost/getimg.xml In the server.xml element (at the bottom of the element) In the webapps directory... This is the context fragment I am using: I then place the following symbolic link in the webapps/getimg directory: ln -s /usr/scratch/images images and reboot tomcat. But, no visibility whatsoever! Of course, when I actually mkdir a directory in webapps/getimg, files in this directory are visible, but not with a symlink, and of course I don't want to have to actually put gigabytes of stuff in the tomcat tree. I have, however, successfully used the context element to point tomcat to my getimg webapp when I have located it outside of the tomcat/webapp directory (for example, with docbase="/tmp/getimg" or docbase="/usr/scratch/getimg") but tomcat and the webapp still cannot see the linked-in subdirectory at all. Pull-eesse help!!! Pleease!! Maurice Yarrow - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
