Re: Better Linux Distribution for production environment
On Thursday, 23 בMarch 2006 13:32, korbben wrote: > Thanks Peter, we have most experience in Fedora Core 1b, but is it a > good distribution for production ? > We use Fedora only for intranet server, but now for a extranet > server, whith maximal security and stability, Fedora is recommended ? As peter mentioned, and I'll stipulate - every distro can be made to be secure (enough) fairly easily if you are familiar with it, and probably no distro will be secured enough if you have no idea what you're doing. If you have experience with Fedora, then go with that. On a general principal I would recommend going with a more recent version, such as Fedora Core 4 on the premise that it has less security issues due to being more up to date, but if you make sure to apply all security updates and upgrade packages that are EOLed, then you should be ok, regardless of which distro you choose. -- Oded ::.. Famous Last words 143-"Here kitty, kitty, kitty..." - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Log4j configuration on a per context basis
On Thursday, 9 בFebruary 2006 16:30, Boris Unckel wrote: > > Guys, how can I setup log4j with a context specific configuration > > file ? > > > > In the past I used to put a global log4j configuration in the > > system classpath for the tomcat, but that is no longer appropriate > > in my current setup. > > Hi, > > remove any log4j.jar and log4j.properties from your global > classpathes (system classpath, common, shared). > Put a log4j.jar and log4j.properties in each WEB-INF/lib (jar) and > WEB-INF/classes (properties) with the correspondent config. Thanks. I figured that something like that would work, but for some non-related issues, I rather not have a classes directory. Is there a way to have a log4j configuration available to the web app w/o putting it in the classes dir or in a jar file ? maybe someway to setup the context.xml to point to a log4j configuration directly in WEB-INF ? -- Oded ::.. The essential ideas of Algol 68 were that the whole language should be precisely defined and that all the pieces should fit together smoothly. The basic idea behind Pascal was that it didn't matter how vague the language specification was (it took *years* to clarify) or how many rough edges there were, as long as the CDC Pascal compiler was fast. -- Richard A. O'Keefe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Log4j configuration on a per context basis
Guys, how can I setup log4j with a context specific configuration file ? In the past I used to put a global log4j configuration in the system classpath for the tomcat, but that is no longer appropriate in my current setup. -- Oded ::.. "Who the hell wants to hear actors talk?" -- H. M. Warner (1881-1958), founder of Warner Brothers, in 1927 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Context files question (may be related to bu 38198)
( http://issues.apache.org/bugzilla/show_bug.cgi?id=38198 ) My conf// context files directory contains files which are logically named (instead of named according to the context path), which is ok as they load fine under tomcat 5.0 (contrary to how tomcat 5.5 behaves, which is what the above bug is all about), but when each context reloads, tomcat copies the context file to a new name, formatted according to the filename-to-context-path conversion discussed in said bug. I turned off auto-deploy in the host's configuration in server.xml, but that doesn't seem to stop this behavior - how do I cause tomcat to stop doing that ? (save for disabling write access to that directory). -- Oded ::.. A man is like a rusty wheel on a rusty cart, He sings his song as he rattles along and then he falls apart. -- Richard Thompson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: rebuild-jar-repository error
On Friday, 13 �January 2006 05:22, Bob Hartung wrote: > I have installed tomcat5, with java 1.5.0.0. > > Now trying to start tomcat5 I get this in the output followed by an > [OK] > >/usr/bin/rebuild-jar-repository error "all detected jars were not > found for this jvm. > > I am not sure what to read at this point. You are using the jpackage RPMs obviously, and that means that not all dependencies are packaged with the tomcat package - 3rd party libraries are packaged separately (as they might also be required by other applications) and the RPM dependency management should alert you to any missing libraries. If you installed the RPM successfully w/o errors, and w/o using --nodeps, then its quite possible that the dependency specifications are not complete, in which case I suggest you contact the packager of the tomcat RPM (as listed in rpm -qi tomcat5) and/or jpackage-discuss and list the entire error output you get when running tomcat. Its should also be possible for you to read the error output and determine what 3rd party libraries are missing and install them directly from JPackage. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9611212 (204) +972-54-7340014 ::.. "Classical Music (klahs i kel myoo zik) n. 1. A complex organization of sounds, akin to noise and cacophony, set down by the composer to be misinterpreted by the conductor, who is disregarded by the musicians, the result of which is ignored by the audience." -- Webster's Dictionary -- Oded ::.. The truth will set you free, but first it will hurt like hell. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding tomcat class path handling
On Friday, 13 בJanuary 2006 01:19, [EMAIL PROTECTED] wrote: > On Mon, Jan 09, 2006 at 08:16:00PM +0200, Oded Arbel wrote: > > The problem is like this (the actual system is far more complex): > > - suppose two web applications, app1 and app2, both use some API > > (which I developed myself). > > - I don't want to develop the API twice on both web applications, > > so I have a third project for the API itself, which is a not a web > > application and so isn't in WEB-INF/classes of neither app1 nor > > app2. - I don't want to build a jar for that API library to put in > > app1 and app2's WEB-INF/lib because its also constantly being > > developed - if I wanted to do this then after each commit, in > > addition to the build stage I would have to copy the jar by hand to > > all the applications that use it, which is an error prone process. > > You've got to be kidding. Copy by hand!? Why? Just build the jar > file to some predefined location, and have the build process for each > app copy it from there. There's no need to copy it by hand, have > ant, or whatever you're using to build, do it for you. The build file that I use to build the web app in the development env is the exact same build file that eventually builds it for distribution. The reason this is so, is that everything in the SCM (Software configuration management - CVS and the likes) for the web app is exactly the same as we use for the final build, so that checking out from SCM and running ant are the only steps required to complete a distribution package - that way we get to do all the code testing in the development environment and the QC is used only for integration testing. > That seems much simpler than playing with custom class loaders, or > startup classpath dependencies, or loose class files. On the contrary. due to the reasons noted above, everything that differs in the development env from the QC env has to be done by hand (when I say by hand, I also mean special development env only scripts that are not stored in SCM. Due to the "not stored in SCM" requirement we strive to keep them as simple as possible so we don't need to track them). > e.g. say you've got 4 different api's. When you build those, a jar > file gets created in (e.g.) /myjars: > Let's say app1 uses api's 1, 3 and 4, so it has something like this > somewhere in its build.xml: (assuming you're using ant) > The dependency on the build env being "just right" and custom to each application (i.e. lack of standard deployment techniques) is the major down side with Java development. In order to solve this, the JPackage project has developed some strict conventions as to what goes where, and I'm not in the habit of violating these as keeping up with the conventions is the number one reducer of development and integration time. The JPackage conventions call for all jars to be installed in a specific directory - /usr/share/java - and be sym-linked from there to where you want. the symlinking IS part of the ant build script, but it works because the locations of the 3rd party jars is known ahead of time because they are installed in the same location for all environments. The problem is that development projects are not "installed" as they are in constant development, and everything which is "installed" has to be installed using the platform package management solution. So, the way our system works is like this: Dev has: 3rd party system packages, development projects, custom stuff Build: get development projects, run ant -> create system package QC and Production: 3rd party and our system packages. What way production does not have any custom hand-installed software, only stuff that plays nice with the built-in software management tools. That allows us to have the operating system supports software versioning and software dependencies and unified software distribution in a transparent way across all of the software products we deploy (3rd party or locally developed), the QC is exactly the same so it allows real testing of what its like to be in production, and the build system is a very simple two step process which is easy to monitor and reproduce on a clean system (hacking the build is kept to minimum and everything is in SCM for easy tracking). This causes the development to have some custom stuff, but again - no hacking of anything that is in SCM. -- Oded ::.. "If I have seen farther than other men, it is because I stood on the shoulders of giants." -- Sir Isaac Newton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding tomcat class path handling
On Wednesday, 11 בJanuary 2006 18:38, Sriram Narayanan wrote: > I wrote something that works for me: > http://issues.apache.org/bugzilla/show_bug.cgi?id=38223 Thanks. I didn't use your implementation for the reason noted in the comment I attached to the issue, but you pointed me in the right direction. I solved the problem by also implementing a web app class loader and attached the source to the above issue. Thanks again :-) -- Oded ::.. Software: Making your computer come alive so it can attack you -- Dave Barry in Cyberspace (probably using Windows) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache + Tomcat, Tomcat only handles JSP in localhost
On Tuesday, 10 בJanuary 2006 14:31, Warren Pace wrote: > > The most important reason that I use an Apache frontend for tomcat, > > which is probably not relevant to the original poster, is that > > under Unix only root processes can open port 80 (the default HTTP > > port), and so if tomcat is configured to serve pages on port 80, it > > must run as root. > You can use jsvc to run tomcat as a non-priviledged user on port 80. That is very interesting - I was not aware of that capability of jsvc. Currently neither of my production operating systems (Mandriva and RedHat) offer this as a package, but I'll check it out. -- Oded ::.. For every minute you are angry, you lose sixty seconds of happiness. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDumperValve screws UTF-8 parameter parsing
On Tuesday, 10 בJanuary 2006 11:16, Endre Stølsvik wrote: > On Tue, 10 Jan 2006, Oded Arbel wrote: > | AFAIK, the catalina implementation of HttpServletRequest does not > | allow to set the character set more then once, even though it > | doesn't do any pre-processing of the input. > | > | Maybe that should be fixed instead ? > > I think that when you "touch" the servlet request object's parameters > at all (or even anything else it might seem like), it parses them all > at once using the then-set (or default) encoding and caches them. > > This is most probably according to spec. > > I really don't find this that problematic ... the browser > sends all its parameters using one encoding, and it would be a > strange setting if it was really needed to change the encoding > "midways" in your processing. Then why is it at all possible to set the encoding ? it should not be needed and there for should not be possible. The fact that such a call exists suggests to me that calling it repeatedly would have some effect (granted - it will slow the performance, but that is as expected) - I would prefer the request implementation reparse everything when I supply new character set information - taking it sweet time to do it (I'm probably only going to do this once per request) - rather then just ignore me. The fact is, if you get at the request too late in the process, where the character set has already been set (wrongly), theres nothing you can do to rescue the data, and many times I've had that problem. -- Oded ::.. -- Members of an avian species of identical plumage congregate. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache + Tomcat, Tomcat only handles JSP in localhost
On Tuesday, 10 בJanuary 2006 02:35, Caldarale, Charles R wrote: > > From: Sriram Narayanan [mailto:[EMAIL PROTECTED] > > Subject: Re: Apache + Tomcat, Tomcat only handles JSP in localhost > > > > The link he gave talks about how to have PHP etc along side Tomcat. > > PHP can be fairly easily used with Tomcat standalone: > http://wiki.apache.org/tomcat/UsingPhp > > So, I repeat: What "full-fledged" features do you think are missing > from Tomcat? The most important reason that I use an Apache frontend for tomcat, which is probably not relevant to the original poster, is that under Unix only root processes can open port 80 (the default HTTP port), and so if tomcat is configured to serve pages on port 80, it must run as root. This is a serious security concern. Apache knows how to open port 80 and then change to a non-privileged user, something which AFAIK tomcat - being based on Java which does not support the concept of operating system privileges - cannot do. There for, some kind of frontend is required. While we are in the process of providing a frontend, it might as well be Apache which offers additional features: reverse-proxying and caching and support for a huge number of scripting languages (python, perl or ruby anyone ?) and other modules. Also - the tomcat support for PHP is really nice and I am planning on trying it out ASAP, but I prefer not to do hacks on production machines, and Apache support for PHP is better integrated and is offered as part of my base operating system - including support for compiled pages, code caches and PHP debugging. -- Oded ::.. Ability is nothing without opportunity. -- Napoleon Bonaparte - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RequestDumperValve screws UTF-8 parameter parsing
On Tuesday, 10 בJanuary 2006 00:06, Endre Stølsvik wrote: > Enabling the RequestDumperValve in both 5.5.12 and 5.0.16 (!) messes > up the parsing of other-than-ISO-8859-1 incoming parameters. > > After using a rather huge bunch of hours, this came down as the > result: when this "debug valve" is turned on, it seems to default to > ISO-8859-1 when it parses and log-outputs the incoming parameters, > thus also implicitly setting the entire Request-object to this enc, > so any subsequnt setting to UTF-8 doesn't matter at all. At least > this is true for POST paramters. AFAIK, the catalina implementation of HttpServletRequest does not allow to set the character set more then once, even though it doesn't do any pre-processing of the input. Maybe that should be fixed instead ? -- Oded ::.. Democracy is also a form of worship. It is the worship of Jackals by Jackasses. -- Henry Louis Mencken - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding tomcat class path handling
> On 1/10/06, Oded Arbel <[EMAIL PROTECTED]> wrote: > >> >> An optimal setup for me, I think, is: >> - for each application to put the 3rd party dependencies in WEB-INF/lib >> (I'm using JPackage's build-jar-repository, which I auto invoke from >> the ant script, so its even automatic). > > I thought you said you were not able to the the classes into jar files > (as that was part of a separate build automation process) ? No - I'm talking here about the 3rd party libraries, which I did not develop and are not part of tomcat - these come as jars. >> - for each application that users locally developed libraries to list >> their build directories in the web.xml so what the WebAppClassLoader >> can get at them without them being shared. >> > > There's no attribute in web.xml that let's you specify separate class > paths to load from. > > What you could do is to write your own WebAppClassLoader that'd add > these folders to its lookup list. Hmm. interesting. How can I let such a class loader implementation to be used instead of tomcat's WebAppClassLoader ? -- Oded - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding tomcat class path handling
On Monday, 9 בJanuary 2006 21:34, Boris Unckel wrote: > > But then, if the API library calls a 3rd party library, that > > library can't be put in WEB-INF/lib either - it has to be put in > > the tomcat's startup classpath as well. > > Ok. I will repeat to ensure I understand it: > You have a development system where you do not want to jar for each > test of your API, you also do not want to war (ant task) before you > test. Your API depends on 3rd party JARs which are not in the default > distribution of Tomcat. Yes, more or less. The problem is not a single locally developed library - the problem is that I have many of those, and each required different third party libraries. > For your development system only (please do not use this on a > production machine): > Put your classes in > TOMCAT_ROOT/shared/classes > (create the folder if not existing) As mentioned above, I have more then one project that requires this treatment - putting the products of all projects in one place is not the way I want to go, as its a mess and it will be hard to know which class belongs to which project, and I may also encounter name conflicts (I don't believe that I have those, but its not guaranteed). > put your libs in > TOMCAT_ROOT/shared/lib I'm trying to avoid the need to put the 3rd party dependencies of all the web applications in a single place - due to the reasons you noted. An optimal setup for me, I think, is: - for each application to put the 3rd party dependencies in WEB-INF/lib (I'm using JPackage's build-jar-repository, which I auto invoke from the ant script, so its even automatic). - for each application that users locally developed libraries to list their build directories in the web.xml so what the WebAppClassLoader can get at them without them being shared. This kind of setup would leave all the mess out of the JVM classpath, would allow me to define on a per web application what I want it to have on the classpath by once editing a simple file, and won't require me to do complex hand-eye coordination routines each time new code is introduced. My current interim solution (which is bad) is to have the continuous build process for each locally developed library also create the jar packages, and then I symbolically link them into the WEB-INF/lib directory. The main down side is that this lengthens the continuous build process by almost twice as much, and so a lot of times I have to wait for eclipse to finish a source code commit (that blocks the user interface) before I can continue to work. -- Oded ::.. I've never been canoeing before, but I imagine there must be just a few simple heuristics you have to remember... Yes, don't fall out, and don't hit rocks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache + Tomcat, Tomcat only handles JSP in localhost
On Monday, 9 בJanuary 2006 20:28, Nelson Maisonet wrote: > Problem: Everything works perfectly when accessing through localhost. > However, when I try to go through the net (domain name), instead of > displaying the website created in .jsp it simply displays the code. > > Background: I ran the tomcat server by itself for quite some time > without any problems, but now I need the functionality of a > full-fledged http server so I'm adding apache and connecting them > together with mod_jk. Only things changed in the tomcat setup is what > the guide asked to be added. Guide used: > http://mpcon.org/apacheguide/jsp.php you are probably accessing the JSP files through the apache server instead of directly through tomcat, and mod_jk isn't configured properly for apache and doesn't handle the JSP files. instead apache handles them directly. You might want to go over the apache error log and the mod_jk log (as specified in the mod_jk configuration) and see if you see any interesting error messages. -- Oded ::.. It's easy to identify people who can't count to ten. They're in front of you in the supermarket express lane. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question regarding tomcat class path handling
On Monday, 9 בJanuary 2006 20:02, Boris Unckel wrote: > > The way I see it, I have two options - either put all the 3rd party > > libraries back in the JVM classpath, or build jars from my locally > > developed libraries and copy them by hand to the web applications' > > folder. I don't like either option, and I would really like a third > > one - something like configuring the default web.xml file to add > > external directories to the web-app class loader ? can something > > like that be done ? > > I do not fully understand your problem, but maybe something simple: > WEB-INF/lib for your jars > WEB-INF/classes for your classes The problem is like this (the actual system is far more complex): - suppose two web applications, app1 and app2, both use some API (which I developed myself). - I don't want to develop the API twice on both web applications, so I have a third project for the API itself, which is a not a web application and so isn't in WEB-INF/classes of neither app1 nor app2. - I don't want to build a jar for that API library to put in app1 and app2's WEB-INF/lib because its also constantly being developed - if I wanted to do this then after each commit, in addition to the build stage I would have to copy the jar by hand to all the applications that use it, which is an error prone process. - so instead I add the directory where the API's class files are built to the tomcat's startup classpath. - But then, if the API library calls a 3rd party library, that library can't be put in WEB-INF/lib either - it has to be put in the tomcat's startup classpath as well. Now imagine about 20 such locally developed API libraries (not all used in all web applications, but a lot of web applications use more then one such library), with inter-dependencies between themselves and dependencies on more then 50 3rd party libraries - the situation gets way out of hand very quickly. Before I put a stop to the madness, the tomcat startup classpath was taking about 15 rows of text in my console. -- Oded ::.. The point of philosophy is to start with something so simple as not to seem worth stating, and to end with something so paradoxical that no one will believe it. -- Bertrand Russell, The Philosophy of Logical Atomism - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question regarding tomcat class path handling
I have a development server where I have several java projects - some of them are web applications and some of them are libraries or other applications. I have a problem as some of the web applications are using libraries developed outside the web application root, and those libraries sometimes use third party jars installed on the system (using JPackage). Previously the system was setup so that everything a web application might ever need to access was set in the JVM classpath for tomcat, so there was (almost) no problems with classloader hierarchy. Recently, in order to make the system more clean and flexible, and to solve some version conflicts (where one web app required one version of a library and another app required another), I've changed the configuration to how its supposed to work (as far as I understand): Tomcat is loaded with a minimal class path, and any additional classes are loaded from jars in the WEB-INF/lib directory. The problem is that the non-web applications and libraries are still loaded on the JVM classpath, as I don't have jars for them: the classes are automatically built when changes are made, so we can try them out in the development environment, but no jars are being built or populated into the system - this is handled by the packaging process which is not part of the development environment. So now if an application uses a local library, and that library required a third party jar, it can't find it. The way I see it, I have two options - either put all the 3rd party libraries back in the JVM classpath, or build jars from my locally developed libraries and copy them by hand to the web applications' folder. I don't like either option, and I would really like a third one - something like configuring the default web.xml file to add external directories to the web-app class loader ? can something like that be done ? TIA -- Oded ::.. "There is no reason anyone would want a computer in their home." -- Ken Olson, president, chairman and founder of Digital Equipment Corp., 1977 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java databases as alternative to MySQL on OS X Server? (OT)
On Tuesday, 29 בNovember 2005 17:28, Caldarale, Charles R wrote: > > From: Oded Arbel [mailto:[EMAIL PROTECTED] > > Subject: Re: Java databases as alternative to MySQL on OS X > > Server? (OT) > > > > inter-thread communication in java is done through shared > > memory - shared variables, but the Java memory sharing model > > doesn't really share memory, Instead it uses thread local > > storage to store copies of shared variables and when you > > cross into or out of a synchronized block, the contents of > > the variables are copied. > > That's one of the most bizarre and blatantly wrong descriptions of > the Java memory model that I've ever read. Rather simplified and not accurate where accuracy would have caused me to get way off topic, but all in all not really incorrect. > All Java objects reside > in the Java heap, which is shared across all threads of the JVM > process and directly referenceable by all. Please read up on your Java memory model. What you describe is a nice abstraction that many Java developers have in their mind, but is technically not correct and can't be correct when you consider multiple processors, DMA, hyper-threading or even just plain old L2 CPU caches. [http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html] [http://www.developer.com/java/article.php/951051] [http://www-128.ibm.com/developerworks/library/j-jtp02244.html] Also please note that JSR-133, once implemented, supposedly makes the whole discussion irrelevant as it forces read/write ordering. But AFAIK, only Sun's JVM 5.0 (1.5) implements it and I'm not sure about its correctness. > Entering a synchronized block in a HotSpot-based JVM normally does > not require any context switching, since the lock on an object is > established via the platform's compare-and-exchange instruction; only > if a conflict exists are kernel services required to suspend the > conflicting thread. You are obviously disregarding the fact that Java is a multi-platform environment, and some platforms (notably the Mac OS-X which started the whole thread) does not provide such a mechanism. Are you an MS-Windows programmer by any chance ? > No copying of local variable is ever > performed; If it ever appeared that I was talking about 'local variables' when I wrote the word 'local' then I'm deeply sorry, and I here-by request that you please re-read my original post more carefully. The word local in this case was used to denote the running thread's view on the shared variables, also knows as "thread local storage" (do look up that concept as well when you read about the Java memory mode, please). -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9611212 (204) +972-54-7340014 ::.. When the student is ready the master appears. -- Japanese proverb - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java databases as alternative to MySQL on OS X Server? (OT)
On Tuesday, 29 בNovember 2005 05:12, Mieke Banderas wrote: > I wonder how much faster Linux could run on my G3 server hardware. I > would have lots of work replacing all the built in services in Mac OS > X Server to give me all that control also in Linux, buy maybe I have > to. I'm a bit cashstrapped for new hardware, so I need to get as much > performance I can. Or perhaps I should try to get a PC just for the > DBs. As Anandtech's tests suggest, a good PC or even Linux on Apple hardware will give you much better performance. This is probably due to the better locking that Linux implements (read about futex() ). That being said, I suspect that Linux on a G3 will give you less performance then you can get today with a midrange PC that would cost you less then US$ 1000 (probably less then half of that if you don't need it rack mounted). BTW - I think that their tests aren't much fair in the hardware department. They compare an end of the line architecture (G5) which hasn't had any serious improvement done for it in the last two years, with the latest and greatest of the two top performers of the micro-computer world, whose chips (same chips that were tested) are powering the worlds fastest super computers. Its a credit to Apple and the G5 line that they only lost by about 10%. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9611212 (204) +972-54-7340014 ::.. "If you sell diamonds, you cannot expect to have many customers. But a diamond is a diamond even if there are no customers." -- Swami Prabhupada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java databases as alternative to MySQL on OS X Server? (OT)
On Tuesday, 29 בNovember 2005 03:21, Mieke Banderas wrote: > Oded Arbel said: > >b) Even assuming they are right, you still want to choose MySQL over > > JVM space databases, because Java and Java databases are very much > > thread enabled and create and destroy many threads. > > But do they do it mainly within the OS or within the JVM? The JVM can't create threads without OS support. Even user-space threads need some OS support. > Top or PS > doesn't show individual processes within the JVM. That means they use kernel threads. > I'm not clear on > how Java processes/threads relate to OS processes/threads. > to know where/how exactly Java threads are started/killed on Hotspot > in OS X. Doesn't java threads mainly intercommunicate within the JVM? > Context switches? Not an OS X expert, but from Anandtech explanations and from what I've read elsewhere, Java threads are kernelthreads and are mapped to Mach threads. inter-thread communication in java is done through shared memory - shared variables, but the Java memory sharing model doesn't really share memory, Instead it uses thread local storage to store copies of shared variables and when you cross into or out of a synchronized block, the contents of the variables are copied. That means a lot of context switches through the kernel, and if you OS doesn't do that very well (and few do it as well as Solaris), then you'd be hard pressed for performance. > Is it really a completely dead end that minimizing the OS threading > in Mac OS X and keeping threads within JVM could improve performance? As discussed above, there isn't much difference. > Of course the Java DB in question would have to be somewhat similar > to MySQL in performance, but possibly the Java DB could perform > better with many connections as that is where MySQL on OS X breaks > down according to anandtech. I believe you wont see much improvement, if at all. > >MySQL OTOH uses very > >little threads - essentially it only creates a new thread to handle > > a new client, and even then a single thread handles several clients > > before another thread is required. > > But according to the anandtech article OS X is the only platform > where performance breaks down after raising the amount of > connections. So it would seem until Apple fixes the performance > problems - which certainly may take a while-, ways to use databases > without creating many expensive (in theory) OS threads could be > desirable. That is if you subscribe to Anandtech's explanation that the poor MySQL performance is the result of poor threading performance. I think I provided enough evidence that their conclusions will not be taken at face value. Again, not an OS X expert, but I think its much more likely that the MySQL have problems with locking and context switches, as Anandtech themselves have mentioned and even quoted MySQL on the issue - and immediately disregarded it in favor of the thread theory. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9611212 (204) +972-54-7340014 ::.. Conscience is what hurts when everything else feels so good. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java databases as alternative to MySQL on OS X Server? (OT)
On Monday, 28 בNovember 2005 19:59, Mieke Banderas wrote: > Given the sad, sad performance findings at: > "No More Apple Mysteries, Part Two" > Date: September 1st, 2005 > <http://www.anandtech.com/mac/showdoc.aspx?i=2520> > I don't enough of JVMs to know if Javabased DBs are usually better > performancewise than MySQL/PostgreSQL, but my thought was that if > everything is kept within the JVM, the weak performance spots in OS X > would be minimized as threads would be handled within JVM rather than > within OS X. Threads being being the prime suspect in the weak MySQL > performance in OS X according Anandtech. After reading the article I can say two things: a) I think their take on the thread vs. process creation issue is completely wrong. They are basically saying "thread creation on linux is the same as process creation and is very fast, but thread creation on MAC OSX is not the same as process creation because process creation also creates a task. Because we tested process creation to be slower on MAC OSX, we conclude that thread creation is slower." Am I the only one that see how broken the logic here ? b) Even assuming they are right, you still want to choose MySQL over JVM space databases, because Java and Java databases are very much thread enabled and create and destroy many threads. MySQL OTOH uses very little threads - essentially it only creates a new thread to handle a new client, and even then a single thread handles several clients before another thread is required. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9611212 (204) +972-54-7340014 ::.. General Failure's Fault. Not Yours. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java databases as alternative to MySQL on OS X Server? (OT)
On Monday, 28 בNovember 2005 19:59, Mieke Banderas wrote: > are there any javabased DB alternatives, that may perform better than > MySQL (or PostgreSQL for that matter)? I prefer free, open sourced > DBs or otherwise with a license that could fit a small business/non > profit organisation. HSQLdb (formerly known as Hypersonic SQL) and Apache Derbi (formerly knows as cloudscape DB) are two Pure Java databases, which are free and open source, and at least the first can run "in memory" in the JVM. As for faster performing ? I think you'd be hard pressed to find something better performing then MySQL and Postgres. Might want to try firebird, though I wouldn't get your hopes up. > I don't enough of JVMs to know if Javabased DBs are usually better > performancewise than MySQL/PostgreSQL, I can't really see how it could be, and my experience indeed shows the opposite. > but my thought was that if > everything is kept within the JVM, the weak performance spots in OS X > would be minimized as threads would be handled within JVM rather than > within OS X. Threads being being the prime suspect in the weak MySQL > performance in OS X according Anandtech. I'm not sure why do they think that, and I haven't read the entire article yet, but I doubt you'd get better performance from an internal DB then from a standalone highly optimized full RDBMs. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9611212 (204) +972-54-7340014 ::.. The marvels of today's modern technology include the development of a soda can, when discarded will last forever ... and a $7,000 car which when properly cared for will rust out in two or three years. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5 error during startup - 2nd connector doesn't work
Hi people. I'm using tomcat5 to host a commercial web site, and due to some integration issues we are using a single service with two CoyoteConnectors - one on port 8080 and one on port 8081. Here is the relevant configuration: I've noticed that some times, when catalina is starting, I get this error in the logs: Nov 24, 2005 4:28:30 PM 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) When that happens, HTTP requests to the second connector (port 8081) return with error 400 - no host matches, while requests to the first connector are handled just fine. It looks to me like a race condition where something (possibly MBeanServerImpl) isn't locking a shared resource (or isn't locking it properly) and an contained HashMap gets modifier concurrently. I though initially about writing to the dev list, but I don't have any idea what is that mx4j so I'm not sure if its the correct place to ask. BTW - I'm using tomcat 5.0.28. TIA -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9611212 (204) +972-54-7340014 ::.. Who the fuck is General Failure? And why is he reading my harddisk? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
