Re: svn commit: r1210786 - in /geronimo/external/trunk/tomcat-archetype: run.sh svn-actions.sh
Just in case you plan to use this script to fetch TC 7 versions: On 06.12.2011 06:27, xiam...@apache.org wrote: Modified: geronimo/external/trunk/tomcat-archetype/svn-actions.sh URL: http://svn.apache.org/viewvc/geronimo/external/trunk/tomcat-archetype/svn-actions.sh?rev=1210786r1=1210785r2=1210786view=diff == --- geronimo/external/trunk/tomcat-archetype/svn-actions.sh (original) +++ geronimo/external/trunk/tomcat-archetype/svn-actions.sh Tue Dec 6 05:27:32 2011 @@ -32,7 +32,7 @@ else RM=rm -rf fi -TOMCAT_BASE=https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_35; +TOMCAT_BASE=https://svn.apache.org/repos/asf/tomcat/trunk; Tomcat 7 has moved to a new tc7.0.x branch a few moths ago. Fetchint trunk won't give you the head of the TC 7 branch, instead you'll get real trunk which is supposed to become TC 8 some time. Regards, Rainer
[jira] [Created] (GERONIMO-6198) UUEncode errors in geronimo-javamail_1.4_spec
UUEncode errors in geronimo-javamail_1.4_spec - Key: GERONIMO-6198 URL: https://issues.apache.org/jira/browse/GERONIMO-6198 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: specs Environment: Any Reporter: Rainer Jung Three bugs in the uuencode implementation corrupt the encoded date. See the following patch: http://people.apache.org/~rjung/patches/geronimo-javamail_1.4_spec-uuencode-r1147270.patch The bug in UUEncoder.java can be seen by encoding 0123456789. The other bug by e.g. encoding a 10 times concatenation of 0123456789. The base for the patch is todays trunk at http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-javamail_1.4_spec. I didn't check, whether other branches are also broken. Regards, Rainer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Discussion] why does geronimo set org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true?
Just in case you wonder what STRICT_SERVLET_COMPLIANCE actually means for Tomcat: you can find some details under http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Specification Regards, Rainer
Re: low entropy on linux systems
On 15.07.2011 04:19, Kevan Miller wrote: From time to time I encounter a problem starting a Geronimo server on a Linux system (I've always seen it on Ubuntu -- but the problem could exist on other distributions). The server start seems to hang. However, if you're patient, which I rarely am, the server will eventually start. If you're inquisitive, and dump the stack traces of the java process, you'll see something like: main prio=10 tid=0x40c0d800 nid=0xa79 runnable [0x7f57a04fb000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:220) at sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:185) at sun.security.provider.NativePRNG$RandomIO.implGenerateSeed(NativePRNG.java:202) - locked 0xdaad63e0 (a java.lang.Object) at sun.security.provider.NativePRNG$RandomIO.access$300(NativePRNG.java:108) at sun.security.provider.NativePRNG.engineGenerateSeed(NativePRNG.java:102) at java.security.SecureRandom.generateSeed(SecureRandom.java:495) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.getSalt(PKCS12KeyStore.java:477) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.calculateMac(PKCS12KeyStore.java:834) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.engineStore(PKCS12KeyStore.java:788) - locked 0xd3b5a768 (a com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore) at java.security.KeyStore.store(KeyStore.java:1117) ... This problem isn't Geronimo specific. But since I see it from time to time, thought it would be worth passing along to the community... The Sun/Oracle-based JVM is attempting to generate a pseudo-random number to be used as a seed for an SSL server socket. To generate the pseudo-random number, the JVM is reading from the /dev/random device to obtain some random information for the seed. The problem is that reads from the /dev/random device will block if the system does not have a good source of random events. So, the Geronimo server startup is blocked waiting for enough random information to be returned from /dev/random. This article may be help understand the basic issue -- http://en.wikipedia.org/wiki//dev/random#Linux I'm no security expert. And I don't know the potential implications, but the simplest way that I've found to avoid the problem is to use the /dev/urandom device, instead of /dev/random. Do this by specifying the following java property '-Djava.security.egd=file:/dev/./urandom'. So, the following should work well: $ GERONIMO_OPTS=-Djava.security.egd=file:/dev/./urandom ./geronimo run --long Note to self -- would be nice to record this on our Wiki somewhere. Anyway, hope this is useful... And note that due to a bug in the JDK you really need to use /dev/./urandom or /dev//urandom and not /dev/urandom. Oracle themselves already internally use dev/urandom, but later they switch from /dev/urandom to /dev/random if the setting is trsingwise identical to /dev/random. That's why you need to use some different string that's equivalent to /dev/urandom after path normalization. We had the same problem for Tomcat, mostly when starting two instances in parallel. Regards, Rainer
Re: low entropy on linux systems
On 15.07.2011 15:56, Rainer Jung wrote: On 15.07.2011 04:19, Kevan Miller wrote: From time to time I encounter a problem starting a Geronimo server on a Linux system (I've always seen it on Ubuntu -- but the problem could exist on other distributions). The server start seems to hang. However, if you're patient, which I rarely am, the server will eventually start. If you're inquisitive, and dump the stack traces of the java process, you'll see something like: main prio=10 tid=0x40c0d800 nid=0xa79 runnable [0x7f57a04fb000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:220) at sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:185) at sun.security.provider.NativePRNG$RandomIO.implGenerateSeed(NativePRNG.java:202) - locked 0xdaad63e0 (a java.lang.Object) at sun.security.provider.NativePRNG$RandomIO.access$300(NativePRNG.java:108) at sun.security.provider.NativePRNG.engineGenerateSeed(NativePRNG.java:102) at java.security.SecureRandom.generateSeed(SecureRandom.java:495) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.getSalt(PKCS12KeyStore.java:477) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.calculateMac(PKCS12KeyStore.java:834) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.engineStore(PKCS12KeyStore.java:788) - locked 0xd3b5a768 (a com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore) at java.security.KeyStore.store(KeyStore.java:1117) ... This problem isn't Geronimo specific. But since I see it from time to time, thought it would be worth passing along to the community... The Sun/Oracle-based JVM is attempting to generate a pseudo-random number to be used as a seed for an SSL server socket. To generate the pseudo-random number, the JVM is reading from the /dev/random device to obtain some random information for the seed. The problem is that reads from the /dev/random device will block if the system does not have a good source of random events. So, the Geronimo server startup is blocked waiting for enough random information to be returned from /dev/random. This article may be help understand the basic issue -- http://en.wikipedia.org/wiki//dev/random#Linux I'm no security expert. And I don't know the potential implications, but the simplest way that I've found to avoid the problem is to use the /dev/urandom device, instead of /dev/random. Do this by specifying the following java property '-Djava.security.egd=file:/dev/./urandom'. So, the following should work well: $ GERONIMO_OPTS=-Djava.security.egd=file:/dev/./urandom ./geronimo run --long Note to self -- would be nice to record this on our Wiki somewhere. Anyway, hope this is useful... And note that due to a bug in the JDK you really need to use /dev/./urandom or /dev//urandom and not /dev/urandom. Oracle themselves already internally use dev/urandom, but later they switch from /dev/urandom to /dev/random if the setting is trsingwise identical to /dev/random. That's why you need to use some different string that's equivalent to /dev/urandom after path normalization. We had the same problem for Tomcat, mostly when starting two instances in parallel. ... and a bit more detail available at: http://marc.info/?l=tomcat-devm=130182757504685w=2 Regards, Rainer
Re: Tomcat version in G1.1
Just for your information: 5.5.16 was released a couple of weeks ago, but has some problems with de delivered packaginf of examples app under windows. 5.5.17 is expected to be cut on friday and voted stable eventually 1-2 weeks later. Jeff Genender wrote: Yep...need to update the plan. Its updated in trunk. Dave Colasurdo wrote: It appears that G1.1 is still using Tomcat 5.5.9 http://svn.apache.org/repos/asf/geronimo/branches/1.1/etc/project.properties Wasn't a tomcat upgrade to 5.5.15 in plan for G1.1?? Perhaps I am confused with the plans for trunk.. ?? Thanks -Dave-
Re: Geronimo peak performance
When preparing for the test, have a look at the very interesting cpustat/cputrack. Without this you won't really be able to judge on the cpu usage. Classical tools like sar/vmstat/prstat easily lead to wrong results (the amount of work a single strand [hardware thread] is able to do is not fixed. It really shares the core with the other strands. If they stall, it will execute on every cycle, if all 4 strands are busy each one will only execute on every 4th cycle. So the cpu power available to a strand is dynamic, but tools like prstat are not able to show that. For memory bus usage busstat is the way to go. If you need more info, you could start an off topic thread or mail me directly. Rainer Jeff Genender wrote: Yep...each core will handle 4 hardware threads. It was built for multiple threads and a JVM (multithreaded of course) is made for this box. For an appserver under load, I think the numbers should be impressive on this box. The cool thing about this machine is, each core is viewed as 4 cpus. That means this box looks like it has 16 CPUs running (4 cores x 4 hardware threads)! I can't wait to pound on this and see what it can do. I am going to have T2000-T2000 trials going on to maximize the throughput for CPU. They come with 4 1 Ghz Ethernet ports each, so I am going to pipe these up and hopefully there will be zero bottleneck on IO.
Re: New binaries
Hi Jeff, I just had a short look at the contents of the tomcat zip. A few comments, but I can not tell, which of these are actually problems. In general: a lot of the subdirs under geronimo-1.0/var do not exist any more: - directory geronimo-1.0/deploy/ does not exist any more (was empty previously) Tomcat stuff: - directory geronimo-1.0/var/catalina/ROOT/ does not exist any more (contained a simple root context previously) - directory geronimo-1.0/var/catalina/conf/ does not exist any more (contained a web.xml previously) - directories geronimo-1.0/var/catalina/logs and geronimo-1.0/var/catalina/work do not exist any more (empty previously) Derby stuff: - directory geronimo-1.0/var/derby/ does not exist any more (contained subdirs geronimo-1.0/var/derby/UddiDatabase/, geronimo-1.0/var/derby/DaytraderDatabase/ and geronimo-1.0/var/derby/SystemDatabase/ previously) ActiveMQ: - directory geronimo-1.0/var/activemq/ does not exist any more (contained subdir journal previously) Naming: - directory geronimo-1.0/var/ldap/ does not exist any more (contained subdir system previouly) Others: - directory geronimo-1.0/var/txlog/ does not exist any more (contained two files how1_[12].log previously) Jeff Genender wrote: Hi, I finally got Internet connectivity from the hotel in San Diego (it was down). I have built new binaries to be reviewed. This is not a vote...its a review...after folks have reviewed this, we can move this to a vote. I have put the binaries here: http://people.apache.org/~jgenender/geronimo/1.0/ Thanks to David Blevins for working with me yesterday to get this completed. Please download these and try them out...and please comment on any issues/changes/naming we need for these. Thanks, Jeff
Re: [Vote] Geronimo V1.0 Release binaries
Hi there, correction to my previous mail: 1) The strange split of all files between the two src archives was a failure on my side. Actually there are exactly the same files in both zip and tarball. 2) The problem with chopped off last characters in file names to some extent still exists, but it looks like a tar compatibility problem: a) Extracting with Solaris tar (even under Solaris 10) shows the problem b) Extracting with gtar 1.13 shows the problem. c) Extracting with gtar 1.14 does NOT show the problem I'm not sure, if the problem is a bug in the extracting tar, or in the archive building tar. The observation is not the usual imcompatibility betwenn standard tar and gtar relatet to path lengths. In the geronimo case the last character ist being chopped off. So I guess this situation now is mostly uncritical, although it would be nice to check, if it's a build side gnu tar problem. Sorry for the hassle Rainer
[OT] tar incompatibilities
Concerning my mails related to strange behaviour of the release tarballs: There is an incompatibility between gnu tar and other tars as well as different versions of gnu tar whenever the name of a file (including path) is exactly 100 chars long. POSIX allows exactly 100 chars without using extension mechanisms, newer gnu tars seem to use their own extension algorithm already starting with length 100. All files with strange behaviour in the release tarballs had path+file name exactly 100 chars long and the last char was chopped off whenever the extracting tar was not compatible (even gnu tar) with the building tar.
Re: [Vote] Geronimo V1.0 Release binaries
Hi guys, unfortunately: -1 (non binding) Reason: The tarballs for source and bin are corrupt. They includes files with a missing last character in their name. I checked md5 of the downloads (OK). The zip seems OK. Some differences between the archives might be intentionally, but obviously not all. Furthermore: there are considerably more files in the src tarball, than in the zip: Concerning the bin archives: geronimo-1.0/config-store/24/geronimo-console-standard-1.0.war/WEB-INF/lib/jasper-runtime-5.5.12.ja geronimo-1.0/config-store/24/geronimo-console-standard-1.0.war/WEB-INF/lib/jasper-runtime-5.5.12.jar The file geronimo-tomcat-j2ee-1.0.zip is contained only in the zip archive. All other differences in the bin are concerning jsps. In geronimo-1.0/config-store/24/geronimo-console-framework-1.0.war/WEB-INF/: aggregation/PageFragment.js aggregation/PageFragment.jsp aggregation/RootFragment.js aggregation/RootFragment.jsp In geronimo-1.0/config-store/24/geronimo-console-standard-1.0.war/WEB-INF/: view/configmanager/deploy.js view/configmanager/deploy.jsp view/configmanager/normal.js view/configmanager/normal.jsp view/dbwizard/basicParams.js view/dbwizard/basicParams.jsp view/derbylogmanager/help.js view/derbylogmanager/view.js view/derbylogmanager/help.jsp view/derbylogmanager/view.jsp view/realmwizard/advanced.js view/realmwizard/advanced.jsp view/realmwizard/showPlan.js view/realmwizard/showPlan.jsp view/servermanager/normal.js view/servermanager/normal.jsp view/webmanager/maximized.js view/webmanager/maximized.jsp Concerning the src archives (much more differences), there is only one file, that is in both, the tarball and the zip. All other files and dirs are only contained in one of them: - geronimo-1.0/applications/* only contained in tar - geronimo-1.0/assemblies/* only contained in tar - geronimo-1.0/bin/* only contained in zip - geronimo-1.0/configs/* only contained in tar - geronimo-1.0/config-store/* only contained in zip - geronimo-1.0/docs/* only contained in tar - geronimo-1.0/modules/* only contained in tar - geronimo-1.0/plugins/* only contained in tar - geronimo-1.0/sandbox/* only contained in tar - geronimo-1.0/lib/* only contained in zip - geronimo-1.0/repository/* only contained in zip - geronimo-1.0/schema/* only contained in zip - geronimo-1.0/var/* only contained in zip - geronimo-1.0/xdocs/* only contained in zip and some individual files: geronimo-1.0/BUILDING.txt geronimo-1.0/COPYRIGHT geronimo-1.0/LICENSE.txt geronimo-1.0/NOTICE.txt geronimo-1.0/PROPOSAL.txt geronimo-1.0/README.txt geronimo-1.0/META-INF/ geronimo-1.0/META-INF/MANIFEST.MF geronimo-1.0/STATUS geronimo-1.0/docs_nopublish/ geronimo-1.0/docs_nopublish/JBoss_20031031.html geronimo-1.0/etc/ geronimo-1.0/etc/geronimo_checks.xml geronimo-1.0/etc/maven.xml geronimo-1.0/etc/project.properties geronimo-1.0/etc/project.xml geronimo-1.0/maven.xml geronimo-1.0/pom.xml geronimo-1.0/project.properties geronimo-1.0/project.xml geronimo-1.0/deploy/ geronimo-tomcat-j2ee-1.0.zip Hopefully only a packaging issue. Rainer
