Re: never say never...
--- "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > Glen Mazza wrote: > > Haroon Rafique wrote: > > > >> On Tuesday at 12:54pm, JB=>Jay Burgess > <[EMAIL PROTECTED]> wrote: > >> > >> JB> The following comments are not intended to be > a personal attack on > >> JB> anyone. However, I can't stand by and watch > George speak my mind > >> for JB> me, word for word, and not chime in and > say "I agree!". Plus, > >> I think JB> if you took a poll, you'd find he > speaks for a large > >> number of list JB> subcribers. > >> > >> Yes Jay, other members have that feeling too. If > we take a look at the > >> recent past, there are various examples of > rudeness, impropriety and > >> lack of respect. > > > > Well, my sympathies are more with the Tomcat > developer team, given the > > abuse they incur from certain unfortunate > individuals in the user > > community. > > You mean by the same unfortunate individuals who > like to abuse their > checkout clerk, bank teller and doctor's > receptionist? Odd, they tend > to excuse themselves that they are paying for that > privilage; Funny > I don't recall seeing a donation check from them to > the ASF. > > Bill I thought about not even writing this. Then I thought about not even submitting it. Don't take it personally how ever it hits anyone. I think it's fair. I think it runs both ways. I think most of the Tomcat developers are really great. I think an unnamed developer could learn how to be a little nicer. I think a good number of users could as well. There is no good excuse for simply being mean and nasty for users nor developers. Without mentioning any names: If one could see a list of what contracts and monetary connections are made through the Apache project for certain members they would see some things a little differently, and I do not mean that any of the developers deserve to be yelled at or belittled. For instance, I'm sure a few JBoss customers might find a couple of bugs and comments associated with them a little disturbing. I would imagine a few other commercial customers of other companies using projects based on Tomcat would as well. This based on my own experiences with aiding in explaining a couple of issues found in Tomcat. Some things do not require arguing about. They simply need to be looked at and egos need not get in the way. So, not to kick up the flames, just being real; I don't think it is as black and white as some people would like to believe in relation to volunteering hours to the project vs being compensated. The same can be said about Eclipse, Netbeans, etc. Many projects today have incorporated corporate interests into their ranks (whether it's admitted or not). Companies employ people to work on these projects, so they aren't doing it for free. Others are contributing their time to also utilize others time and selling products based on these open source projects and making a good amount of money doing so. Then some 3rd party softwares based on these solutions are bought by users. The company they purchased their software from spends money in donations or contributes developers to the projects. Money = Time and Time = Money. Lets face it, if these companies were not making money from from these open source projects they would not be contributing. They like the collective free time and work, which is also why many contribute to projects. Others contribute in their free time one way or another mostly just for fun. Anyways, many thanks to the Tomcat developers. I think almost every one of them are really great guys. Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: never say never...
--- Bill Barker <[EMAIL PROTECTED]> wrote: > > > > -Original Message----- > > From: Wade Chandler > [mailto:[EMAIL PROTECTED] > > Sent: Friday, February 24, 2006 4:57 PM > > To: Tomcat Developers List > > Subject: Re: never say never... > > > > --- "William A. Rowe, Jr." <[EMAIL PROTECTED]> > > wrote: > > > > > Anyways, many thanks to the Tomcat developers. I > > think almost every one of them are really great > guys. > > I'm not certain how Amy is going to take that ;-). > > > > > Wade > > Yes to be politically correct. :-D They are really great people. Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Challenges for Java hosting
Just some thoughts based on what Tim has mentioned. --- Tim Funk <[EMAIL PROTECTED]> wrote: > I was thinking that too. A big problem with JVM's is > memory leaks. I would say a big problem any application is memory leaks. C and C++ have the same types of issues...just a little different along with cleaned up pointers being referenced from other objects no causing access violations as they are now null(0) or junk. Profilers can be ran against both types of projects as long as you can find one for the given platform. Java is a little easier per the profiler interface. >The easy > solution is to restart tomcat. But that causes a > period of downtime due to > waiting for a restart. > > Why not make mod_ajp "smarter" or create a tomcat > launcher where some parent > process (apache, or the launcher) listens for > requests from the public and > uses AJP to have tomcat serve the requests. [The > downside is added latenency] I like this idea. Something like this: > > The parent process can spawn a new tomcat after some > configurable time and > kill the old one. By using the cluster code - the > sessions can be synced > before the old tomcat goes away. With the XML scheme above it would watch each JVM process and restart it after some time. > > This mechanism could also be used as a way to > perform graceful restarts too > where an web app upgrade is done and reloading > webapps will cause memory leaks. Yes each process could then be killed off regardless of worrying about threads. JVM hooks can be used to start shutting down the process and the admin can give the shutdown/restart command of a given context or host a time limit and if the shutdown fails to take <=X amount of time then the process will be killed. The developer will be responsible for only using daemon threads if they spawn their own threads. > [Disclaimer: the above ramblings may not be based in > reality] I think it is realistic...obviously it would take some reworking and a good amount of timeI mean this may not even be realistic, but it would certainly be more inline with a good hosting solution and make it more flexible. I think using a Tomcat launcher would be best and then filter AJP through the front process like happens now, and that process filter to it's sub processes using AJP because IMO one should be able to only use Tomcat and not have to use both httpd and Tomcat unless they just really want to ,and I think localhost TCP/IP loopback with AJP would be fine as it doesn't have the same overhead as TCP/IP over a network interface and will be handled in memory buffers, but being able to have the Tomcat front end communicate with other Tomcat front ends over AJP so one could define a host be ported through this instance to another instance on another machine would be nice as well so it's all clustered from the Tomcat configuration and all Tomcat basedworkers could be defined in the server configuration for a Host or down to the Context/Application level. I think it would make sense to have AJP not pool local loopback connections, and only pool Network interface connections because they are software based connections anyways and don't really have anything to do with an Ethernet (or what ever HW scheme) connection and a real network connection...they are much fastermaybe only reuse them if they reach a certain count as to help avoid running out of TCP/IP connections on the computer, but reduce that level and not reuse them unless traffic is very heavy. This way local loopback AJP can support more connections...and really how much overhead is avoided by pooling the local loopback connections (obviously it makes a huge difference for real connections)? > > -Tim Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Challenges for Java hosting
--- "Preston L. Bannister" <[EMAIL PROTECTED]> wrote: > Again, the main question is which target you are > trying to hit. > > Are you aiming at Java web hosting where a hosting > service would offer Java > to *all* their customers? > > Are you aiming at Java web hosting for any (or > nearly any) existing Java web > application? > > In the first case you are aiming at the niche where > PHP has found great > success. On a purely theoretical level, PHP as a > solution should not > exist. On a practical level, there are all sorts of > reasons why (at > present) Java is a PITA for web hosting services, > and PHP is easy to > accomodate. In this problem domain the vast > majority of sites are very low > usage. > > In the second case you are aiming at a much smaller > niche. Playing games to > keep a pool of JVMs with per-user-application > in-memory state makes sense. > This is almost certainly going to translate to > greater trouble and > complexity for the hosting service. More trouble > means a higher priced > service offered less often. > > If your aim to make Java ubiquitous (which I believe > possible) then you want > to target the first case. > > For low-traffic websites the probability of a GC > during the process of a > single request is low. Also - though I can't say > I've looked at the latest > GC implementations in detail, the trend (starting > with generational GC) in > algorithms was to not move long-lived stuff around. > Taken together, it is > reasonable to assume that GC is not going to have > much (or any) impact. > > This is aiming at the niche where PHP is popular - a > rather large niche. > > What you are looking for is the simplest thing that > can possibly work. You > don't need JVM enhancements. You don't need to add > complexity in terms of > managing pools (always fun). You don't need to > worry about leaky > abstractions. Odds are you end up with something > simple and dead reliable > for a hosting service to deploy. A hosting service I use has a good scheme with using multiple workers. Each Tomcat is it's own instance, and points to the domain folder where we have the common files and places for classes...shared...commonthe config files. They then have rules we have to follow as far as developing, or they'll let you know you need to change somethingsame would happen for PHP...some page using all the processor. But, other than that, we have our own directory, our own process for the JVM, and we have ssh shell access to the things we need, but overall nothing that could not be handled through a web interface. It works out really well, and we have several domains we support on it. Doesn't seem any more difficult than anything I've done with PHP other than the classes and folder and things and every now and then restarting the TC instance. Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat & JDK for PDA arm processor
--- "Frank W. Zammetti" <[EMAIL PROTECTED]> wrote: > Nearly every PDA with that much RAM doesn't actually > have that much > RAM... the problem is, WinCE itself uses up a lot of > it. For instance, > I sit here with my Dell Axim x51v with 64Mb, yet I > have 29Mb available, > and I have nothing installed at the moment, just had > to do a hard > restart last night. That's why most of the JREs out > there are trimmed > down. There may be some exception to that, but I am > not aware of it. > > Your right, there are some with 128Mb these days, > and it's possible to > hardware-hack them up to 256Mb I believe, but you > can't count on having > all of it available. A big chunk of it is going to > be taken up. > > Also note that at least with the Windows Mobile 5 > devices, there is a > difference between RAM and Flash ROM. PPC's used to > have one big chunk > of memory that would be dynamically allocated > between "program memory" > (RAM for all practical purposes) and "storage > memory". Now though, > there really is two physically different things. > For instance, My Axim > has 256Mb Flash ROM, probably about 210Mb or so of > it starts out free. > You can think of this as a hard drive for the most > part, it's yours to > store stuff in (and the OS to a limited degree I > believe). There tends > to be enough storage space on modern PPCs to do Java > and Tomcat and your > app, its the RAM where I think you'll run into a > problem with. > > I don't know off hand how much memory Tomcat itself > needs, but I'd be > willing to bet 29Mb would be kind of tight, and > that's not counting the > JRE or your app. > > I definitely think you may want to consider not > doing a webapp here, > unless the PDAs will always have net connectivity, > then you could just > write a true webapp tailored somewhat to a PDA. If you need to connect to a server like application on the PDA use some type of a simple TCP/IP protocol you write yourself to handle just what you need. > > The good news is that PPC programming these days > isn't too big a deal... > C# is enough like Java that you can probably get by > with it. If you do > .Net, it won't be too much different than > programming for Java. You'd be hard pressed getting less RAM usage out of the .NET Framework when you compare apples to apples (application vs application designed the same and doing the same things). If you are used to Java use it. > > That of course means your app won't be > cross-platform, no Zaurus for > example. Dunno if you can get away with that or > not. Why would you even bother with .NET if you have Java and a good modularized application. At least with java applications you can reuse some of your classes from your desktop..beans and such. Harder to do with .NET and the Compact and Desktop projects provided by Visual Studio. I have even done this with Sun Java and Super Waba...pretty much copies of files to get the same with .NET if you use your standard toolshave fun writing build scripts. > > Frank Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URLStreamHandler and ContentHandler
--- Shankar Unni <[EMAIL PROTECTED]> wrote: > Yoav Shapira wrote: > > > More on topic, I don't mind switching Tomcat to > java.util.logging > > Umm, please don't do that. For those of us who > *have* mastered the art > of using log4j with Tomcat (:-)), this would be a > giant step back > (having one logging mechanism for Tomcat and one for > the webapps - and I > don't want to go to java.util.Logging for our > apps!). > > While I think the current situation is a bit > unfortunate and requires a > fair degree of knowledge of classloader hierarchies, > it's at least a > workable setup for most users today. You will still be able to use your log4j while Tomcat uses a different internal logging package. If you have based your logging on some TC specific things then that isn't really good and this type of thing would be why it should be considered bad practice (if you are really dependent upon the logging API used by TC that is). Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn lock: /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/jni/Error.java
Yes this sucks. We can't even easily filter the mails out on our ends because of the way they are sent. We could look for svn, but what if a message is really related to svn. Wade --- Andy Piper <[EMAIL PROTECTED]> wrote: > The level of svn spam here is ridiculous, can we > redirect svn > messages to [EMAIL PROTECTED] or something? > > Thanks > > andy > > At 13:08 20/07/2006, [EMAIL PROTECTED] wrote: > >Author: mturk > >Comment: > >SVN Propset in progress. > > > >Locked paths: > > > tomcat/tc6.0.x/trunk/java/org/apache/tomcat/jni/Error.java > > > > > >- > >To unsubscribe, e-mail: > [EMAIL PROTECTED] > >For additional commands, e-mail: > [EMAIL PROTECTED] > > ___ > Notice: This email message, together with any > attachments, may contain > information of BEA Systems, Inc., its > subsidiaries and affiliated > entities, that may be confidential, proprietary, > copyrighted and/or > legally privileged, and is intended solely for the > use of the individual > or entity named in this message. If you are not the > intended recipient, > and have received this message in error, please > immediately return this > by email and then delete it. > > - > 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]
