RE: Tomcat 5.5.4 tomorrow (Friday) instead of Saturday?
fine by me. Filip -Original Message- From: Shapira, Yoav [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 2:16 PM To: Tomcat Developers List Subject: Tomcat 5.5.4 tomorrow (Friday) instead of Saturday? Hi, Would everyone be OK with cutting the 5.5.4 release tomorrow (Friday, October 29th) instead of Saturday (October 30th) as we originally agreed? It'd be more convenient for me, that's the only reason. If it can't be done on Friday, it'll likely have to be Monday afternoon instead, but Saturday I can't do. As for the release time of day, it'll be the same whether Friday or Monday: 1900h GMT which is 1400h my time (US Eastern time zone). Yoav Shapira http://www.yoavshapira.com This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.778 / Virus Database: 525 - Release Date: 10/15/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.778 / Virus Database: 525 - Release Date: 10/15/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] [5.5] Release plan votes
ballot I approve the release plan: [X] Yes [ ] No /ballot ballot Tomcat 5.5 should use the following API set for the coding: [ ] J2SE 1.3 [X] J2SE 1.4 [ ] J2SE 5.0 /ballot ballot Yoav Shapira will act as the release manager for this branch: [X] Yes [ ] No /ballot --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.740 / Virus Database: 494 - Release Date: 8/16/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Load balance in tomcat
guys, please move this stuff to tomcat-user, I see the same people over and over posting user related questions to tomcat-dev Filip -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 17, 2004 9:40 AM To: [EMAIL PROTECTED] Subject: AW: Load balance in tomcat Hi, You can use you favourite load balancing hardware or software, e.g. WLBS. Then set up tomcat in cluster mode. Drawbacks are slightly less performance and all your session data has to be serializeable. -- Björn Andersen www.premiere.de -Ursprüngliche Nachricht- Von: Henrique Faria [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 17. August 2004 16:34 An: [EMAIL PROTECTED] Betreff: Load balance in tomcat Hi! Which is the best way to load balance, across multiple tomcat instances, without using jk conectors or apache web servers? Is there support for it in the Catalina core? Thanks, Henrique Faria Senior Consultant Java Software Team tel:55.11.3285 4699 cel:55.11.9811 8281 fax: 55.11.3266 5121 [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] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.735 / Virus Database: 489 - Release Date: 8/6/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.735 / Virus Database: 489 - Release Date: 8/6/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Dynamic updates and Apache v2.0
why are we so focused on dynamic this dynamic that, there is nothing about mod_proxy that is dynamic, and instead of delaying the stability and release of a working mod_proxy with a load balancer, make it work, make it work well, then add fancy features. mod_jk2 became way to cluttered this exact way, and never got to the point of workability to the point where any user could configure it just my $0.02 Filip -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache Sent: Monday, July 26, 2004 11:30 AM To: [EMAIL PROTECTED] Subject: Re: Dynamic updates and Apache v2.0 First, by dynamic updates I mean changes to apache2 config that don't require a restart. For example, .htaccess files provide such a thing ( for a different area ). What updates ? There are several forms: 1. - add a new worker to a pool ( for example - expect big load, you buy more hardware, etc ). - gracefully remove a worker ( for upgrade for example ) - the implication is that sticky sessions will still go, no new sessions. - change parameters of a worker ( like balancing factors ). That may include advanced balancing. Note that for all this you don't actually need too much change on apache/mod_proxy - as long as you treat the pool as one entity, and maybe use a separate config file for the list of workers ( so you don't have to regenerate httpd.conf - which is quite difficult ). There are many ways to implement the communication between httpd processes and between apache and tomcat. 2. - add more webapps and virtual servers - for example in the case of an ISP. - reload webapps - that means some mappings and auth changes, in the case of tight integration you may want to have apache handle auth and mapping Costin Graham Leggett wrote: Hi all, I am starting a new thread for this, as it seems to be an important killer-app feature for any httpd v2.0 integration. People have said the config should be dynamically configurable - which part of the config should be dynamically configurable? In other words, would any of these senarios make sense: - A potential pool of servers (IP address/port combinations) is defined, and httpd gracefully handles the case where a server is missing. Adding a new server is as simple as starting it up on one of the predefined ip/ports combinations. An admin might configure an entire subnet as tomcat servers, and then add and remove backend servers at will. Easy to do, but a bit limiting. - httpd is informed via a special URL of updates to the servers on the backend, a bit like the management app in tomcat. This functionality might grow to being available to the whole httpd config. Being a URL, it would be pretected by standard mechanisms like SSL and basic authentication. Powerful, but a big change that will likely only appear in httpd v2.1 or v2.2. - httpd polls the backend servers using the OPTIONS method (as was recommended recently). In the info returned, httpd learns of the intended weighting of the servers, whether a server needs to be removed gracefully from the pool, or whether other servers have been added to the pool and should be included in the config. Here httpd needs only to be told about just one backend server, which will seed httpd with info about all the other servers. Out of the above three the third option seems to make the most sense. It's not very obtrusive, it can be used with backends other than tomcat. Actually updating the server list and weightings can be done via the tomcat management app, which already exists now (as opposed to a theoritical management app for httpd). Thoughts? Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev
added to summarization, missing stickiness 1. Set a cookie on the clients machine - no server memory to hold a map 2. If the client doesn't accept cookies, do a simple sticky load balancing based on the IP of the client request. Again, no memory map needed. -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 21, 2004 8:17 PM To: Tomcat Developers List Subject: Re: Simple Sticky LB WAS: Invitation to HTTPD commiters in tomcat-dev I'm not sure of the status so far, but I'd like to summarize a strawman. I have no idea how to code this at this time or if it can be done. -- *Config* [Feel free to change the names] ProxyClient http://server1/config.xml ProxyClient http://server2/config.xml ProxyClient http://server3/another/config.xml ProxyUpdate /proxyconfig *Startup* Apache polls each proxy-client for existence and config at the URL defined by te ProxyClient directive. Each proxy-client states the paths/extension/mimetype/??? it can serve as well as its weight. *On going* Apache periodically polls the config URL for changes. --or-- A proxy-client can join, remove, alter URL availability by using making a request to apache defined at ProxyUpdate. *Edge cases* Authentication, environment variables, and other system parameters would be passed to the proxy via X-Headers. Apache would need to deny/filter these header names from outside clients. *stickyness* unknown how to fix this in a generic manner *Failover* 2 cases 1) server unavailable - easy to recover since a new connection is made 2) server available but doesn't handle request anymore - Proxy-client returns a custom header to let apache move to next node? *Changes to tomcat* Add a proxy mode flag to allow for the X- headers to pass authentication and other variables. Add to the manager(?) app and method to expose all the URL spaces availble. Minor changes to fix getRemoteAddr() to show the client, not the apache server. Pros - Simple(?) and not tomcat specific. Cons - Duplicate (re)parsing of headers, probably higher latency than jk. -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.next] Progress
hi Remy, Time will open up in a week or so. And yes, I am wide open to any ideas. My personal feeling about the farm deployer, is that it would work exactly like auto deployment to Tomcat, and maybe just an entry in web.xml makes it send to other servers. I do need a temp directory to store the fragments of data sent across the wire, so that we don't take up too much RAM. Let me put together a todo list for review next week! Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, July 15, 2004 12:11 PM To: Tomcat Developers List Subject: Re: [5.next] Progress My updated TODO. So I'll do the deployer next, followed by trying to optimize startup time. Then, there's tweaking. Filip, do you have time to refactor the clustering soon ? I think we should tweak your farming feature as well, as it should likely be done the way the manager servlet is (rather, will be) doing its stuff. The idea is to have only one big entry point for deployments, rather than have 20 different components calling various deploy methods (which is impossible to maintain). I need to write some code and experiment, and then I'll have a clearer view of what this refactoring will look like (sorry, it's just a little too messy right now for me to enumerate the list of changes). - Attempt to redo a bit the deployer: * remove the CL code which is there to avoid JAR locking (or at least allow disabling this feature for non-Windows OSes); when enabling anti locking code, move everything to a temp deploy folder where everything will be referenced from; controlled by a development flag on the Context to allow disabling this on Windows * move processing of context.xml to StandardContext (at the expense of being able to specify the context class, which will move to an attribute on the Host), as I realize it is important to get context level configurability without adding too much complexity in the embedding application; this could also go in ContextConfig, but this should be done in another event (START occurs too late) - Use the webapp CL as the main CL (without the locking tricks it is likely faster than the regular CL) - Resolve DBCP - Pool - Collections dependency, using package renaming - Remove anything useless (spring cleaning time), such as configuration options, container listeners (to be replaced with JMX notifications where it matters), etc - clutering module refactoring, to extend the regular Catalina objects, for easier future maintenance - Possibly require JDK 1.5 (cleaner code, annotations, integrated JMX and JMX remote, etc) - Externalize configuration saving out of StandardServer - And the ongoing: allow all config/management through JMX (actually, we could consider going to a JMX config format) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.713 / Virus Database: 469 - Release Date: 6/30/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.next] Progress
This is how it works currently. There is a listen directory. If you deploy an app to any of the nodes on the cluster, into the listen directory, it will deploy that app to the other nodes in the cluster. It deploys it into a deployed dir, if an app is removed from that dir, a message is broadcasted to the other nodes to undeploy the app. So it could work the same way, but use the tomcat dirs instead of new ones. And yes, the work dir is the place to store the file fragments. cheerios Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Saturday, July 17, 2004 1:05 PM To: Tomcat Developers List Subject: Re: [5.next] Progress Filip Hanik (lists) wrote: hi Remy, Time will open up in a week or so. And yes, I am wide open to any ideas. My personal feeling about the farm deployer, is that it would work exactly like auto deployment to Tomcat, and maybe just an entry in web.xml makes it send to other servers. Yes for the first part. I think it's misleading to call that the autodeployer, though, as that component will become the deployer (the deployment code is spread and duplicated right now, so the spaghetti needs to go). For the second part, I don't understand. This seems to hint at the existence of a master node, which would be bad, no ? I do need a temp directory to store the fragments of data sent across the wire, so that we don't take up too much RAM. I don't get that sent data thing, but you can use either the workdir or the tempdir (as usual). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.721 / Virus Database: 477 - Release Date: 7/16/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Any synchronization issues with SMP?
The only time I have seen something like this happen is when we had a memory leak, an interesting one. We were running on solaris, our CPU, sometimes one, sometimes both would go up to 100% and stay there. sometimes for as much as 10 minutes and then go back to normal again. We ran thread analyzer (a neat util on solaris) to measure which thread was using a lot of cpu, and found out it was a VM thread. In our scenario, we had a thread being an inner class of an object, and the thread (inner class) referenced the parent and the parent referenced the thread. Even though nothing referenced any of the two objects, it would not be garbage collected, I suspect it had to do with the fact that the inner class was a thread object. Another guess we had was that the VM thread was freakin out cause it tried to resolve garbage collection references and kept looking our weird dependency. Once we resolved the memory leak (removed any references from the parent object to the thread and vice versa) our CPU usage never behaved weirdly again. hope this helps Filip -Original Message- From: Martin Schulz [mailto:[EMAIL PROTECTED] Sent: Friday, June 25, 2004 8:24 PM To: Tomcat Developers List Subject: Re: Any synchronization issues with SMP? it appears that the JVM slows everything down to a crawl, including the code path which should lead to another accept being called., for up to 8 minutes!!! Furthermore, the mpstat has the nice porperty that CPU usage adds up to exactly 100%, i.e. a single CPU is used... no more, no less. This corresponds to 12% or 13% CPU utilization shown in prstat based on 8 CPUs. My interpretation is that the JVM is effectively preventing parallel execution (which otherwise appears to work fine). Nearly all threads either wait, read from a Socket, or zip/unzip data. I'm not sure what all that means, but Tomcat appears to be a victim of it. I'll experiment some more. Main difference with the systems Rainer mentioned is the JVM (1.4.2_04) and the CPU (Sparc III 1.2GHz). If any of this rings a bell, drop me a note. I'll be happy to share data as appropriate. I'll repost to the list only if I learn anything which impacts Tomcat directly (other than that the code path to hand of the socket accept responsibility is not suitable for _very_ high hit rates, which does not worry me too much at this point). Cheers! Martin Martin Schulz wrote: Rainer, Thanks for the tips. I am about to take timing stats internally in the ThreadPool and the Tcp workers. Also, the described symptoms do not disappear, but seem to be of much shorter duration when only 4 CPUs are used for the application. I'll summarize what I find. Martin Rainer Jung wrote: Hi, we know one application running on 9 systems with 4 US II CPUs each under Solaris 9. Peak request rates at 20 requests/second per system. Tomcat is 4.1.29, Java is 1.3.1_09. No symptoms like yours! You should send a signal QUIT to the jvm process during the unresponsiveness time. This is a general JVM mechanism (at least for sun JVMs). The signal writes a stack trace for each thread on STDOUT (so you should also start tomcat with redirection of STDOUT the output to some file). Beware: older JVM in rare cases stopped working after getting this signal (not expected with 1.3.1_09). In this stack dump you should be able to figure out, in which methods most of your threads stay and what the status is. Is there native code included (via JNI)? Any synchronization done in the application itself? Are you using Tomcat clustering? Which JVM? Sincerely Rainer Jung - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.706 / Virus Database: 462 - Release Date: 6/14/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.706 / Virus Database: 462 - Release Date: 6/14/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session facade not used for event
ok, I can do this tomorrow. Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 01, 2004 5:09 PM To: Tomcat Developers List Subject: Re: session facade not used for event Filip Hanik - Dev wrote: Facading is likely worthless for sessions, you think so, you don't think session.setPrincipal is a security issue? Missed that one ;) As Jean-François said, the security manager will avoid the problem. I think it won't hurt replacing the thiss with getSession()s in the event constructors, though. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.692 / Virus Database: 453 - Release Date: 5/28/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.692 / Virus Database: 453 - Release Date: 5/28/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Time for 5.0.26?
I think 5.0.x should be put in a tomcat_5_branch, while the refactoring is done in HEAD. Or I use a separate folder. I would agree that the refactoring should be done in HEAD, and put 5.0.x in a branch Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Sunday, May 30, 2004 9:21 AM To: Tomcat Developers List Subject: Re: Time for 5.0.26? Filip Hanik (lists) wrote: BTW, is it ok if I start my refatoring(s) in a separate branch based on go ahead, refator. :-) I'll refator then. I'll redo logging as well, and define c-l categories (for webapps, for example) to be able to eventually remove Logger altogether. Other things: - attempt to redo a bit the deployer to be able to remove the CL code which is there to avoid JAR locking (and then use the optimized CL for the whole container); this is for faster startup - switch to something other than digester to remove some commons deps (?) (I'm thinking about beanutils and collections); if we don't do that, I think we should do package renaming on these utilities to lower the likelihood of a user being locked into a specific release - I'll try to avoid touching the sensitive stuff as much as possible (connector, anything related with the servlet API impl) to avoid regressions (obviously the two branches will need to remain synced) I think 5.0.x should be put in a tomcat_5_branch, while the refactoring is done in HEAD. Or I use a separate folder. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.692 / Virus Database: 453 - Release Date: 5/28/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.692 / Virus Database: 453 - Release Date: 5/28/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Time for 5.0.26?
BTW, is it ok if I start my refatoring(s) in a separate branch based on go ahead, refator. :-) --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.676 / Virus Database: 438 - Release Date: 5/3/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Facades for OS and W
Bug 28347 had good entertaining value you are so humble ;-) it is an interesting and fully valid test case to test our systems under extreme concurrency by one user, he he he Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 13, 2004 8:34 AM To: Tomcat Developers List Subject: Facades for OS and W Hi, Bug 28347 had good entertaining value. Since I had time to spare yesterday afternoon, I investigated it a little (which was rather interesting). After going nuts for a while, I determined the problem is simply that the output stream and writer need facades (maybe because the API used have some threading issues), which I propose adding in sercurity manager enabled mode (as usual). I'll also try doing the cookie optimization I talked about earlier. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.654 / Virus Database: 419 - Release Date: 4/6/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.654 / Virus Database: 419 - Release Date: 4/6/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0.22] Release vote
ballot Release 5.0.22 as Stable: [ ] Yes [ ] No [x] Prefer not to :) /ballot -0 I don't think we should relase a stable with a few bugs we can fix easily, a lot of people don't read the release notes, and might start filing bugs against them, so we will lose the time later anyway. There were several check ins after the tag, from different committers, so I think it would benefit us to cut a new tag. If I am the only one that feels like this, then I will redraw my vote. Filip -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: Friday, April 09, 2004 9:57 AM To: Tomcat Developers List Subject: Re: [5.0.22] Release vote Remy Maucherat wrote: ballot Release 5.0.22 as Stable: [ ] Yes [ ] No /ballot I've tested the new Windows wrapper, and it did work for me (and it looks as if we did hire some M$ guy to do its UI). However, some more testing is needed (note: it's not suppoed to work on Win9x for now). Another risky change is the upgrade to Xerces 1.6.2. I didn't put the latest docs bundle on the website (AFAIK, the changelog will be the only update, so I think I'll only upload this file). I didn't run the CTS yet with that build. Did the 5.0.22 will include my patch in jk/java/org/apache/jk/common JkMX.java to set correctly the RMI port ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.654 / Virus Database: 419 - Release Date: 4/6/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.654 / Virus Database: 419 - Release Date: 4/6/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: TC Cluster: does SmartQueue fit into DeltaManager
no, smart queue does not belong with the delta manager. it could never work that way, and never will :) Filip -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 06, 2004 1:35 AM To: [EMAIL PROTECTED] Subject: TC Cluster: does SmartQueue fit into DeltaManager Hi, I opened Bug 28161 last week. I found out yesterday, that the problem comes from using the SmartQueue together with DeltaManager and asynchronous replication (see Bug-Report for details). What are the plans now? If I knew, that a fix will take several days I might substitute the SmartQueue by an improvised FIFO to proceed with further tests on our application. Any comments are welcome, especially your opinion on the problem and on what to expect technically and with respect to time frame from a fix. Thank you for the important and very good work you all do on Tomcat. Sincerely Rainer Jung kippdata informationstechnologie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.614 / Virus Database: 393 - Release Date: 3/5/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.614 / Virus Database: 393 - Release Date: 3/5/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 5.0.22 tag ?
sounds good! Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 06, 2004 5:48 PM To: Tomcat Developers List Subject: 5.0.22 tag ? I plan to tag 5.0.22 tomorrow. Any objections ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.654 / Virus Database: 419 - Release Date: 4/6/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.654 / Virus Database: 419 - Release Date: 4/6/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session DeltaSession.java
for the longest time the standard session wasn't extendable. I would have loved to do that a long time ago, now it is just a matter of time before I will do it. 5.0.22 would be good :) thanks Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Friday, April 02, 2004 5:18 AM To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cl uster/session DeltaSession.java [EMAIL PROTECTED] wrote: fhanik 2004/04/01 13:06:50 Modified: modules/cluster/src/share/org/apache/catalina/cluster/session DeltaSession.java Log: bugfix for 28131, thanks to rainer.jung -at- kippdata.de So I assume you're going to want a 5.0.22 ? :( This is a consequence of not extending StandardSession. Is this really not possible to do ? In JBoss, it works fine, and it avoids that kind of maintenance issue. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.614 / Virus Database: 393 - Release Date: 3/5/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.614 / Virus Database: 393 - Release Date: 3/5/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Tomcat as top level ASF Project
This is a tough decision. A top level project can give us more leverage, but it is also way more politics. Politics require mature representation...and are we sure that Tomcat has this. Unless becoming a TLP gives us an instant advantage or will change some things that really do need to change, is it worth the time and effort. IMHO becoming a TLP should have a really good reason, political leverage is a reason, is it validated? One of our big barriers today is the licensing issue, but that is still in the being resolved mode. There was an email to all committers yesterday saying to not turn things upside down quite yet, as they want to try to address the issue. Quoted: For now, don't worry about taking any harsh measures to deal with third-party code. Ensure you're following their licenses, of course, but a formal policy will be drafted up and discussed. For me, my vote would be 0. Cause at present moment, unless I worked for an organization that paid me to get involved in all the politics of a PMC, I just want to write code, not push papers around. Best Filip --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.614 / Virus Database: 393 - Release Date: 3/5/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Next release
end of next week sounds good. I have some very minor fixes, and they I have to update the documentation. After that I will start working on the following: 1. Node merging, improve on the merge algorithm when two cluster nodes find each other 2. A primary/secondary replication solution, to be used if you have sticky sessions, for big clusters and faster performance Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 1:36 AM To: Tomcat Developers List Subject: [5.0] Next release Hi, I'd like to follow on with the one-release-a-month rythm for now, since we still have interesting bugfixes here and there (ex: the cross context fix, plus some JSP fixes). So this means tagging 5.0.20 at the end of next week. It would be a good idea to attempt to fix all the remaining BZ items. - some SSI changes need to be merged back (23610) - plenty of admin webapp patches need to be merged; Amy and Larry were the last persons seen maintaining this feature, so can one of you two do it if you have time ? - the JK bugs should be resolved shortly with the new release - 27296: I think Filip did fix it already - 27259: I don't know ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Next release
oh yeah, and the bugs have been fixed :) (27296,27259) -Original Message- From: Filip Hanik (lists) [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 8:10 AM To: Tomcat Developers List Subject: RE: [5.0] Next release end of next week sounds good. I have some very minor fixes, and they I have to update the documentation. After that I will start working on the following: 1. Node merging, improve on the merge algorithm when two cluster nodes find each other 2. A primary/secondary replication solution, to be used if you have sticky sessions, for big clusters and faster performance Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 1:36 AM To: Tomcat Developers List Subject: [5.0] Next release Hi, I'd like to follow on with the one-release-a-month rythm for now, since we still have interesting bugfixes here and there (ex: the cross context fix, plus some JSP fixes). So this means tagging 5.0.20 at the end of next week. It would be a good idea to attempt to fix all the remaining BZ items. - some SSI changes need to be merged back (23610) - plenty of admin webapp patches need to be merged; Amy and Larry were the last persons seen maintaining this feature, so can one of you two do it if you have time ? - the JK bugs should be resolved shortly with the new release - 27296: I think Filip did fix it already - 27259: I don't know ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.594 / Virus Database: 377 - Release Date: 2/24/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0.19] Release vote
ballot Release 5.0.19 as Stable: [X] Yes [ ] No /ballot Clustering had a major configuration change, but is much more cleaner now. Next step is to make it configurable. But it remains stable. Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, February 16, 2004 4:42 AM To: Tomcat Developers List Subject: [5.0.19] Release vote ballot Release 5.0.19 as Stable: [ ] Yes [ ] No /ballot Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.577 / Virus Database: 366 - Release Date: 2/3/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.577 / Virus Database: 366 - Release Date: 2/3/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5] Broken build - cluster.MembershipFactory
fixed :) Filip -Original Message- From: Jeanfrancois Arcand [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 7:20 AM To: Tomcat Developers List Subject: [5] Broken build - cluster.MembershipFactory Hi, the nightly failled: build-catalina-cluster: [javac] Compiling 40 source files to /disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-5/build/classes [javac] /disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-catalina/modules/clu ster/src/share/org/apache/catalina/cluster/tcp/SimpleTcpCluster.java:91: cannot resolve symbol [javac] symbol : class MembershipFactory [javac] location: package cluster [javac] import org.apache.catalina.cluster.MembershipFactory; [javac]^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 1 error BUILD FAILED file:/disk/raid0/home/jfarcand/jakarta-tomcat/jakarta-tomcat-catalina/modul es/cluster/build.xml:83: Compile failed; see the compiler error output for details. T Filip? ;-) -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.577 / Virus Database: 366 - Release Date: 2/3/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.577 / Virus Database: 366 - Release Date: 2/3/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Converting Coyote to Java2 collections
no complaints here :) just be careful of those ConcurrentModificationException(s) that are lurking in the iterators :-) Filip -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, February 02, 2004 11:54 AM To: Tomcat Developers List Subject: Converting Coyote to Java2 collections Are there any big complaints if I convert Coyote to use Java2 collections ? (less sync) Or is the pure JDK 1.1 compatibility still a big plus ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
