Re: Modified dist.xml to produce platform native packages
Mladen Turk wrote: > As you might see from the SVN log I added few more dist files. > The newly created files are: > > apache-tomcat-7.0.0-dev-win32-x86-native.zip > apache-tomcat-7.0.0-dev-win64-ia64-native.zip > apache-tomcat-7.0.0-dev-win64-x86_64-native.zip > apache-tomcat-7.0.0-dev-windows-x86-native.zip > apache-tomcat-7.0.0-dev-windows-ia64-native.zip > apache-tomcat-7.0.0-dev-windows-x64-native.zip In terms of the windows bit, I am happy with either of the above. I think the native part of the name could create confusion with the native/APR connector download. I wonder if it would be better to just have this for the service wrapper download and name it "...-service.zip"? If we did that, then could we make this Tomcat version independent so the same download would work with 5, 6 or 7? That does mean we end up with multiple downloads again. Hmm. Perhaps it would be better to produce 3 zips in the binary distribution that have everything (Tomcat, native/APR and service) for x86, ia84 and x86_64. > IMO the *-native.zip files patch is safe for bacport > on 5.5 and 6.0, so I'll make a standard VOTE proposal for that, > when we settle the package naming. +1 Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Modified dist.xml to produce platform native packages
Mark Thomas wrote: Mladen Turk wrote: As you might see from the SVN log I added few more dist files. The newly created files are: apache-tomcat-7.0.0-dev-win32-x86-native.zip apache-tomcat-7.0.0-dev-win64-ia64-native.zip apache-tomcat-7.0.0-dev-win64-x86_64-native.zip apache-tomcat-7.0.0-dev-windows-x86-native.zip apache-tomcat-7.0.0-dev-windows-ia64-native.zip apache-tomcat-7.0.0-dev-windows-x64-native.zip In terms of the windows bit, I am happy with either of the above. I think the native part of the name could create confusion with the native/APR connector download. I wonder if it would be better to just have this for the service wrapper download and name it "...-service.zip"? If we did that, then could we make this Tomcat version independent so the same download would work with 5, 6 or 7? The problem with native is that we have multiple releases of them. This confuses users which version to use for which tomcat release. In the end, it is exactly the same as for .exe installer where we determine the native version at build time, just like here. Native releases in that case will be used for both producing the packages and bug fixes. Say; For Tomcat x.y.z upgrade native to version tomcat-native-a.b.c Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r785952 - in /tomcat/trunk/test/org/apache/catalina/valves: ./ Benchmarks.java
Author: markt
Date: Thu Jun 18 08:32:29 2009
New Revision: 785952
URL: http://svn.apache.org/viewvc?rev=785952&view=rev
Log:
Add some micro-benchmarks that enable the differences between the Sync and
ThreadLocal approach to be compared
Added:
tomcat/trunk/test/org/apache/catalina/valves/
tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java
Added: tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java?rev=785952&view=auto
==
--- tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java (added)
+++ tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java Thu Jun 18
08:32:29 2009
@@ -0,0 +1,260 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.catalina.valves;
+
+import java.text.SimpleDateFormat;
+import java.util.Date;
+
+import junit.framework.TestCase;
+
+/**
+ * Some simple micro-benchmarks to help determine best approach for thread
+ * safety in valves, particularly the {...@link AccessLogValve}. Implemented as
+ * JUnit tests to make the simple to execute but does not used Test* as the
+ * class name to avoid being included in the automated unit tests.
+ */
+public class Benchmarks extends TestCase {
+public void testAccessLogGetDate() throws Exception {
+// Is it better to use a sync or a thread local here?
+BenchmarkTest getDate = new GetDateBenchmarkTest();
+getDate.doTest(5);
+}
+
+private static class GetDateBenchmarkTest extends BenchmarkTest {
+private long currentMillis = 0;
+private Date currentDate = null;
+
+private ThreadLocal currentMillisLocal = new ThreadLocal()
{
+protected Long initialValue() {
+return Long.valueOf(0);
+}
+};
+
+private ThreadLocal currentDateLocal = new ThreadLocal();
+
+public Object doSync() {
+long systime = System.currentTimeMillis();
+if ((systime - currentMillis) > 1000) {
+synchronized (this) {
+if ((systime - currentMillis) > 1000) {
+currentDate = new Date(systime);
+currentMillis = systime;
+}
+}
+}
+return currentDate;
+}
+
+public Object doLocal() {
+long systime = System.currentTimeMillis();
+if ((systime - currentMillisLocal.get().longValue()) > 1000) {
+currentDateLocal.set(new Date(systime));
+currentMillisLocal.set(Long.valueOf(systime));
+}
+return currentDateLocal.get();
+}
+}
+
+
+public void testAccessLogTimeDateElement() throws Exception {
+// Is it better to use a sync or a thread local here?
+BenchmarkTest timeDateElement = new TimeDateElementBenchmarkTest();
+timeDateElement.doTest(5);
+}
+
+private static class TimeDateElementBenchmarkTest extends BenchmarkTest {
+private long currentMillis = 0;
+private Date currentDate = null;
+private String currentDateString = null;
+private SimpleDateFormat dayFormatter = new SimpleDateFormat("dd");
+private SimpleDateFormat monthFormatter = new SimpleDateFormat("MM");
+private SimpleDateFormat yearFormatter = new SimpleDateFormat("");
+private SimpleDateFormat timeFormatter = new
SimpleDateFormat("hh:mm:ss");
+
+private ThreadLocal currentMillisLocal = new ThreadLocal()
{
+protected Long initialValue() {
+return Long.valueOf(0);
+}
+};
+private ThreadLocal currentDateLocal = new ThreadLocal();
+private ThreadLocal dayFormatterLocal =
+new ThreadLocal() {
+protected SimpleDateFormat initialValue() {
+return new SimpleDateFormat("dd");
+}
+};
+private ThreadLocal monthFormatterLocal =
+new ThreadLocal() {
+protected SimpleDateFormat initi
Re: Modified dist.xml to produce platform native packages
Mladen Turk wrote: > Mark Thomas wrote: >> Mladen Turk wrote: >>> As you might see from the SVN log I added few more dist files. >>> The newly created files are: >>> >>> apache-tomcat-7.0.0-dev-win32-x86-native.zip >>> apache-tomcat-7.0.0-dev-win64-ia64-native.zip >>> apache-tomcat-7.0.0-dev-win64-x86_64-native.zip >> >>> apache-tomcat-7.0.0-dev-windows-x86-native.zip >>> apache-tomcat-7.0.0-dev-windows-ia64-native.zip >>> apache-tomcat-7.0.0-dev-windows-x64-native.zip >> >> In terms of the windows bit, I am happy with either of the above. >> >> I think the native part of the name could create confusion with the >> native/APR >> connector download. I wonder if it would be better to just have this >> for the >> service wrapper download and name it "...-service.zip"? If we did >> that, then >> could we make this Tomcat version independent so the same download >> would work >> with 5, 6 or 7? >> > > The problem with native is that we have multiple releases of them. > This confuses users which version to use for which tomcat release. > In the end, it is exactly the same as for .exe installer where we > determine the native version at build time, just like here. > > Native releases in that case will be used for both producing the > packages and bug fixes. Say; For Tomcat x.y.z upgrade native > to version tomcat-native-a.b.c I'm all for simplifying things for users. How about the replacing the current single Tomcat binary zip distribution with 3 distributions that contain Tomcat, APR/native connector and the service wrapper for each of the three windows architectures. That way each user only has do get one download and they'll have everything they need. We can still distribute APR/native separately if we want/need to (eg bug fix). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r785961 - /tomcat/current/tc5.5.x/STATUS.txt
Author: markt Date: Thu Jun 18 08:52:01 2009 New Revision: 785961 URL: http://svn.apache.org/viewvc?rev=785961&view=rev Log: Add some comments re thread safety Modified: tomcat/current/tc5.5.x/STATUS.txt Modified: tomcat/current/tc5.5.x/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/current/tc5.5.x/STATUS.txt?rev=785961&r1=785960&r2=785961&view=diff == --- tomcat/current/tc5.5.x/STATUS.txt (original) +++ tomcat/current/tc5.5.x/STATUS.txt Thu Jun 18 08:52:01 2009 @@ -45,6 +45,9 @@ +1: markt, rjung +1: kkolinko (ok, but I propose an additional patch below) -1: fhanik - sounds like a use case for ThreadLocal, synchronized this on a valve is bad + markt - This is post response having been sent to the client so the syncs are less of + an issue. Further, the micro-benchmarks suggests that the syncs are a little + quicker. * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=38483 Make access log valves thread safe (part 2) @@ -56,6 +59,11 @@ +1: kkolinko -1: fhanik - I don't see how this is more thread safe than before. A thread can still call writer.println(message) while another thread has called close() but not yet open + markt - Strictly, the sync is required to protect access to the fileDateFormatter object + Based on the microbenchmarks for the other syncs, I suspect a sync here will be + faster than a ThreadLocal. + The patch appears to use tabs rather than spaces + The issue Filip identified with writing messages when the file is being rotated is still an issue * Fix use of setLoopbackMode() for tribes multicast. in container/modules/cluster/src/share/org/apache/catalina/cluster/mcast/McastServiceImpl.java - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Modified dist.xml to produce platform native packages
Mark Thomas wrote: How about the replacing the current single Tomcat binary zip distribution with 3 distributions that contain Tomcat, APR/native connector and the service wrapper for each of the three windows architectures. That way each user only has do get one download and they'll have everything they need. I'm not for that approach. The standard .zip distro should contain only the bare tomcat. Everything else like docs, deployer etc are already in separate packages. The point is to have the same functionality as with .exe installer but from individual peaces, just like you select which sections to install from the installer. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Modified dist.xml to produce platform native packages
Mladen Turk wrote: > Mark Thomas wrote: >> >> How about the replacing the current single Tomcat binary zip >> distribution with 3 >> distributions that contain Tomcat, APR/native connector and the >> service wrapper >> for each of the three windows architectures. That way each user only >> has do get >> one download and they'll have everything they need. > > I'm not for that approach. > The standard .zip distro should contain only the bare tomcat. > Everything else like docs, deployer etc are already in separate packages. > The point is to have the same functionality as with .exe installer > but from individual peaces, just like you select which sections to > install from the installer. In which case the service component needs to be separate from the native/APR connector component. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r785980 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: markt Date: Thu Jun 18 09:21:42 2009 New Revision: 785980 URL: http://svn.apache.org/viewvc?rev=785980&view=rev Log: Vote Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=785980&r1=785979&r2=785980&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jun 18 09:21:42 2009 @@ -146,7 +146,7 @@ * Additional patch: Do not increment access counter in PersistentValve http://svn.apache.org/viewvc?rev=784602&view=rev - +1: kkolinko + +1: kkolinko, markt -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r785983 - /tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
Author: markt
Date: Thu Jun 18 09:25:00 2009
New Revision: 785983
URL: http://svn.apache.org/viewvc?rev=785983&view=rev
Log:
Expand sync within rotatable block to fix a couple of issues:
- fileDateFormatter is a SimpleDateFormat which is not thread safe
- the rotationLastChecked needs to be volatile to ensure we don't execute the
sync'd block multiple times
Although this is a sync on 'this' in log which gets called for every request:
- a similar sync occurs in getDate() for every request with minimal
performance impact
- microbenchmarks suggest that a sync on 'this' has similar performance to
using ThreadLocals
Based on kkolinko's patch for Tomcat 5.5.x
Note there remains an issue with writing to the log if the log files happens
to be in the process of rotating
Modified:
tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
Modified: tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java?rev=785983&r1=785982&r2=785983&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java (original)
+++ tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java Thu Jun 18
09:25:00 2009
@@ -295,7 +295,7 @@
/**
* Instant when the log daily rotation was last checked.
*/
-private long rotationLastChecked = 0L;
+private volatile long rotationLastChecked = 0L;
/**
* Do we check for log file existence? Helpful if an external
@@ -649,19 +649,21 @@
// Only do a logfile switch check once a second, max.
long systime = System.currentTimeMillis();
if ((systime - rotationLastChecked) > 1000) {
-
-rotationLastChecked = systime;
-
-// Check for a change of date
-String tsDate = fileDateFormatter.format(new Date(systime));
-
-// If the date has changed, switch log files
-if (!dateStamp.equals(tsDate)) {
-synchronized (this) {
+synchronized(this) {
+if ((systime - rotationLastChecked) > 1000) {
+rotationLastChecked = systime;
+
+String tsDate;
+// Check for a change of date
+tsDate = fileDateFormatter.format(new Date(systime));
+
+// If the date has changed, switch log files
if (!dateStamp.equals(tsDate)) {
-close();
-dateStamp = tsDate;
-open();
+if (!dateStamp.equals(tsDate)) {
+close();
+dateStamp = tsDate;
+open();
+}
}
}
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Modified dist.xml to produce platform native packages
Mark Thomas wrote: Mladen Turk wrote: The standard .zip distro should contain only the bare tomcat. Everything else like docs, deployer etc are already in separate packages. The point is to have the same functionality as with .exe installer but from individual peaces, just like you select which sections to install from the installer. In which case the service component needs to be separate from the native/APR connector component. Well, it would be simpler to have just one platform/cpu dist for 'everything-native' instead three more zips thought. Just one note to the previous reply... IMO the .zip distro should be exactly the same as .tar.gz distro (I'm not even convinced we absolutely need CR-LF line endings). The reason is that some platforms have limited default tar implementation like Solaris (especially for long file names and paths). So, to find a common denominator, how about: apache-tomcat-0.0.0.zip apache-tomcat-0.0.0-windows-x86.zip apache-tomcat-0.0.0-windows-x64.zip apache-tomcat-0.0.0-windows-i64.zip The latest three would contain everything from apache-tomcat-0.0.0.zip + service wrapper + native. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r785952 - in /tomcat/trunk/test/org/apache/catalina/valves: ./ Benchmarks.java
2009/6/18 :
> Author: markt
> Date: Thu Jun 18 08:32:29 2009
> New Revision: 785952
>
> URL: http://svn.apache.org/viewvc?rev=785952&view=rev
> Log:
> Add some micro-benchmarks that enable the differences between the Sync and
> ThreadLocal approach to be compared
>
> Added:
> tomcat/trunk/test/org/apache/catalina/valves/
> tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java
>
> (...)
> + private ThreadLocal yearFormatterLocal =
> + new ThreadLocal() {
> + protected SimpleDateFormat initialValue() {
> + return new SimpleDateFormat("");
> + }
> + };
> + private ThreadLocal timeFormatterLocal =
> + new ThreadLocal() {
> + protected SimpleDateFormat initialValue() {
> + return new SimpleDateFormat("hh:mm:ss");
> + }
> + };
> +
I wonder,
may be we can have a single ThreadLocal that holds some object
that stores all the formatters (maybe with lazy initialization),
instead of wrapping each one individually?
Will it make some difference?
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47389] New: DeltaManager doesn't do the session replication. (notifySessionListenersOnReplication=false)
https://issues.apache.org/bugzilla/show_bug.cgi?id=47389
Summary: DeltaManager doesn't do the session replication.
(notifySessionListenersOnReplication=false)
Product: Tomcat 6
Version: 6.0.20
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Cluster
AssignedTo: dev@tomcat.apache.org
ReportedBy: fujino.keii...@oss.ntt.co.jp
DeltaManager is used.
When notifySessionListenersOnReplication is set to false, session replication
is not done.
This cause is in the following DeltaManager#handleSESSION_CREATED's codes.
protected void handleSESSION_CREATED(SessionMessage msg,Member sender) {
...
if(notifySessionListenersOnReplication)
session.setId(msg.getSessionID());
else
session.setIdInternal(msg.getSessionID());
session.resetDeltaRequest();
session.endAccess();
}
When notifySessionListenersOnReplication is false, only session.setIdInternal
is executed.
Session is not added to session map of DeltaManager in session.setIdInternal
method.
As a result, session replication is not done.
When notifySessionListenersOnReplication is false,
I think that I should add session to session map of DeltaManager.
For instance, as follows.
[start.]
Index: java/org/apache/catalina/ha/session/DeltaManager.java
===
--- java/org/apache/catalina/ha/session/DeltaManager.java(revision 763870 (
https://svn.apache.org/viewcvs.cgi?view=rev&rev=763870 ))
+++ java/org/apache/catalina/ha/session/DeltaManager.java(working copy)
@@ -1435,10 +1435,12 @@
// use container maxInactiveInterval so that session will expire
correctly in case of primary transfer
session.setMaxInactiveInterval(getMaxInactiveInterval());
session.access();
-if(notifySessionListenersOnReplication)
+if(notifySessionListenersOnReplication) {
session.setId(msg.getSessionID());
-else
+} else {
session.setIdInternal(msg.getSessionID());
+add(session);
+}
session.resetDeltaRequest();
session.endAccess();
[end.]
Best regards.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r785952 - in /tomcat/trunk/test/org/apache/catalina/valves: ./ Benchmarks.java
I think this needs to be volatile ? In (GetDateBenchmarkTest) > +private long currentMillis = 0; Same for (in TimeDateElementBenchmarkTest) > +private Date currentDate = null; Of course - since the test is single threaded - it doesn't really matter. -Tim ma...@apache.org wrote: Author: markt Date: Thu Jun 18 08:32:29 2009 New Revision: 785952 URL: http://svn.apache.org/viewvc?rev=785952&view=rev Log: Add some micro-benchmarks that enable the differences between the Sync and ThreadLocal approach to be compared - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Modified dist.xml to produce platform native packages
Mladen Turk wrote: > Mark Thomas wrote: >> Mladen Turk wrote: >>> The standard .zip distro should contain only the bare tomcat. >>> Everything else like docs, deployer etc are already in separate >>> packages. >>> The point is to have the same functionality as with .exe installer >>> but from individual peaces, just like you select which sections to >>> install from the installer. >> >> In which case the service component needs to be separate from the >> native/APR >> connector component. >> > > Well, it would be simpler to have just one platform/cpu dist for > 'everything-native' instead three more zips thought. > > > Just one note to the previous reply... > IMO the .zip distro should be exactly the same as .tar.gz distro +1 > (I'm not even convinced we absolutely need CR-LF line endings). > The reason is that some platforms have limited default tar implementation > like Solaris (especially for long file names and paths). I see where you are coming from but I think the line ending changes should stay. > So, to find a common denominator, how about: > apache-tomcat-0.0.0.zip > > apache-tomcat-0.0.0-windows-x86.zip > apache-tomcat-0.0.0-windows-x64.zip > apache-tomcat-0.0.0-windows-i64.zip > The latest three would contain everything from > apache-tomcat-0.0.0.zip + service wrapper + native. +1. If we get feedback from users that suggests changes we can re-evaluate. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r785952 - in /tomcat/trunk/test/org/apache/catalina/valves: ./ Benchmarks.java
Tim Funk wrote: > I think this needs to be volatile ? > In (GetDateBenchmarkTest) >> +private long currentMillis = 0; > > Same for (in TimeDateElementBenchmarkTest) >> +private Date currentDate = null; > > Of course - since the test is single threaded - it doesn't really matter. The test should be multi-threaded unless I got something badly wrong. I'll double check. Making those volatile gets them closer to the real code. I doubt it will make a difference but worth changing to be sure. You never know with these things. Mark > > -Tim > > ma...@apache.org wrote: >> Author: markt >> Date: Thu Jun 18 08:32:29 2009 >> New Revision: 785952 >> >> URL: http://svn.apache.org/viewvc?rev=785952&view=rev >> Log: >> Add some micro-benchmarks that enable the differences between the Sync >> and ThreadLocal approach to be compared > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r785952 - in /tomcat/trunk/test/org/apache/catalina/valves: ./ Benchmarks.java
Konstantin Kolinko wrote:
> 2009/6/18 :
>> Author: markt
>> Date: Thu Jun 18 08:32:29 2009
>> New Revision: 785952
>>
>> URL: http://svn.apache.org/viewvc?rev=785952&view=rev
>> Log:
>> Add some micro-benchmarks that enable the differences between the Sync and
>> ThreadLocal approach to be compared
>>
>> Added:
>>tomcat/trunk/test/org/apache/catalina/valves/
>>tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java
>>
>> (...)
>> +private ThreadLocal yearFormatterLocal =
>> +new ThreadLocal() {
>> +protected SimpleDateFormat initialValue() {
>> +return new SimpleDateFormat("");
>> +}
>> +};
>> +private ThreadLocal timeFormatterLocal =
>> +new ThreadLocal() {
>> +protected SimpleDateFormat initialValue() {
>> +return new SimpleDateFormat("hh:mm:ss");
>> +}
>> +};
>> +
>
> I wonder,
> may be we can have a single ThreadLocal that holds some object
> that stores all the formatters (maybe with lazy initialization),
> instead of wrapping each one individually?
>
> Will it make some difference?
Don't know. You could always add your own test to the benchmarks and find out :)
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r786045 - /tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java
Author: markt
Date: Thu Jun 18 12:58:07 2009
New Revision: 786045
URL: http://svn.apache.org/viewvc?rev=786045&view=rev
Log:
Add volatiles as suggested by Tim to align code with AccessLogValve.
No significant change to results (on my machine at least ;)
Modified:
tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java
Modified: tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java?rev=786045&r1=786044&r2=786045&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java (original)
+++ tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java Thu Jun 18
12:58:07 2009
@@ -36,7 +36,7 @@
}
private static class GetDateBenchmarkTest extends BenchmarkTest {
-private long currentMillis = 0;
+private volatile long currentMillis = 0;
private Date currentDate = null;
private ThreadLocal currentMillisLocal = new ThreadLocal()
{
@@ -78,8 +78,8 @@
}
private static class TimeDateElementBenchmarkTest extends BenchmarkTest {
-private long currentMillis = 0;
-private Date currentDate = null;
+private volatile long currentMillis = 0;
+private volatile Date currentDate = null;
private String currentDateString = null;
private SimpleDateFormat dayFormatter = new SimpleDateFormat("dd");
private SimpleDateFormat monthFormatter = new SimpleDateFormat("MM");
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r785983 - /tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
Do we really need to synchronize on "this" rather than separate some
individual locks for better lock granularity?
2009/6/18
> Author: markt
> Date: Thu Jun 18 09:25:00 2009
> New Revision: 785983
>
> URL: http://svn.apache.org/viewvc?rev=785983&view=rev
> Log:
> Expand sync within rotatable block to fix a couple of issues:
> - fileDateFormatter is a SimpleDateFormat which is not thread safe
> - the rotationLastChecked needs to be volatile to ensure we don't execute
> the sync'd block multiple times
> Although this is a sync on 'this' in log which gets called for every
> request:
> - a similar sync occurs in getDate() for every request with minimal
> performance impact
> - microbenchmarks suggest that a sync on 'this' has similar performance to
> using ThreadLocals
>
> Based on kkolinko's patch for Tomcat 5.5.x
>
> Note there remains an issue with writing to the log if the log files
> happens to be in the process of rotating
>
> Modified:
>tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
>
> Modified: tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java?rev=785983&r1=785982&r2=785983&view=diff
>
> ==
> --- tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
> (original)
> +++ tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java Thu
> Jun 18 09:25:00 2009
> @@ -295,7 +295,7 @@
> /**
> * Instant when the log daily rotation was last checked.
> */
> -private long rotationLastChecked = 0L;
> +private volatile long rotationLastChecked = 0L;
>
> /**
> * Do we check for log file existence? Helpful if an external
> @@ -649,19 +649,21 @@
> // Only do a logfile switch check once a second, max.
> long systime = System.currentTimeMillis();
> if ((systime - rotationLastChecked) > 1000) {
> -
> -rotationLastChecked = systime;
> -
> -// Check for a change of date
> -String tsDate = fileDateFormatter.format(new
> Date(systime));
> -
> -// If the date has changed, switch log files
> -if (!dateStamp.equals(tsDate)) {
> -synchronized (this) {
> +synchronized(this) {
> +if ((systime - rotationLastChecked) > 1000) {
> +rotationLastChecked = systime;
> +
> +String tsDate;
> +// Check for a change of date
> +tsDate = fileDateFormatter.format(new
> Date(systime));
> +
> +// If the date has changed, switch log files
> if (!dateStamp.equals(tsDate)) {
> -close();
> -dateStamp = tsDate;
> -open();
> +if (!dateStamp.equals(tsDate)) {
> +close();
> +dateStamp = tsDate;
> +open();
> +}
> }
> }
> }
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
--
Sincerely yours and Best Regards,
Xie Xiaodong
Re: svn commit: r785983 - /tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
Xie Xiaodong wrote:
> Do we really need to synchronize on "this" rather than separate some
> individual locks for better lock granularity?
Looking at the benchmarks and the times for 10,000,000 iterations even with
additional competition for locks I don't think we need the complexity. I'd want
to see evidence (benchmark, user report etc) that a problem exists before making
more changes, particularly ones that add complexity.
If you want to look at this then I'd be happy to review a patch that added
benchmark to test exactly this issue.
Mark
>
>
>
> 2009/6/18
>
>> Author: markt
>> Date: Thu Jun 18 09:25:00 2009
>> New Revision: 785983
>>
>> URL: http://svn.apache.org/viewvc?rev=785983&view=rev
>> Log:
>> Expand sync within rotatable block to fix a couple of issues:
>> - fileDateFormatter is a SimpleDateFormat which is not thread safe
>> - the rotationLastChecked needs to be volatile to ensure we don't execute
>> the sync'd block multiple times
>> Although this is a sync on 'this' in log which gets called for every
>> request:
>> - a similar sync occurs in getDate() for every request with minimal
>> performance impact
>> - microbenchmarks suggest that a sync on 'this' has similar performance to
>> using ThreadLocals
>>
>> Based on kkolinko's patch for Tomcat 5.5.x
>>
>> Note there remains an issue with writing to the log if the log files
>> happens to be in the process of rotating
>>
>> Modified:
>>tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
>>
>> Modified: tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
>> URL:
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java?rev=785983&r1=785982&r2=785983&view=diff
>>
>> ==
>> --- tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java
>> (original)
>> +++ tomcat/trunk/java/org/apache/catalina/valves/AccessLogValve.java Thu
>> Jun 18 09:25:00 2009
>> @@ -295,7 +295,7 @@
>> /**
>> * Instant when the log daily rotation was last checked.
>> */
>> -private long rotationLastChecked = 0L;
>> +private volatile long rotationLastChecked = 0L;
>>
>> /**
>> * Do we check for log file existence? Helpful if an external
>> @@ -649,19 +649,21 @@
>> // Only do a logfile switch check once a second, max.
>> long systime = System.currentTimeMillis();
>> if ((systime - rotationLastChecked) > 1000) {
>> -
>> -rotationLastChecked = systime;
>> -
>> -// Check for a change of date
>> -String tsDate = fileDateFormatter.format(new
>> Date(systime));
>> -
>> -// If the date has changed, switch log files
>> -if (!dateStamp.equals(tsDate)) {
>> -synchronized (this) {
>> +synchronized(this) {
>> +if ((systime - rotationLastChecked) > 1000) {
>> +rotationLastChecked = systime;
>> +
>> +String tsDate;
>> +// Check for a change of date
>> +tsDate = fileDateFormatter.format(new
>> Date(systime));
>> +
>> +// If the date has changed, switch log files
>> if (!dateStamp.equals(tsDate)) {
>> -close();
>> -dateStamp = tsDate;
>> -open();
>> +if (!dateStamp.equals(tsDate)) {
>> +close();
>> +dateStamp = tsDate;
>> +open();
>> +}
>> }
>> }
>> }
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r785952 - in /tomcat/trunk/test/org/apache/catalina/valves: ./ Benchmarks.java
Mark, since each of your thread runs a TestThread which implements runnable,
those thread do not access the field or method of other threads, I do not
think the test is multi-threaded. You could use one or two
your BenchmarkTest class, and let more than more thread access its method
instead.
2009/6/18 Mark Thomas
> Konstantin Kolinko wrote:
> > 2009/6/18 :
> >> Author: markt
> >> Date: Thu Jun 18 08:32:29 2009
> >> New Revision: 785952
> >>
> >> URL: http://svn.apache.org/viewvc?rev=785952&view=rev
> >> Log:
> >> Add some micro-benchmarks that enable the differences between the Sync
> and ThreadLocal approach to be compared
> >>
> >> Added:
> >>tomcat/trunk/test/org/apache/catalina/valves/
> >>tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java
> >>
> >> (...)
> >> +private ThreadLocal yearFormatterLocal =
> >> +new ThreadLocal() {
> >> +protected SimpleDateFormat initialValue() {
> >> +return new SimpleDateFormat("");
> >> +}
> >> +};
> >> +private ThreadLocal timeFormatterLocal =
> >> +new ThreadLocal() {
> >> +protected SimpleDateFormat initialValue() {
> >> +return new SimpleDateFormat("hh:mm:ss");
> >> +}
> >> +};
> >> +
> >
> > I wonder,
> > may be we can have a single ThreadLocal that holds some object
> > that stores all the formatters (maybe with lazy initialization),
> > instead of wrapping each one individually?
> >
> > Will it make some difference?
>
> Don't know. You could always add your own test to the benchmarks and find
> out :)
>
> Mark
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
--
Sincerely yours and Best Regards,
Xie Xiaodong
Re: svn commit: r785952 - in /tomcat/trunk/test/org/apache/catalina/valves: ./ Benchmarks.java
sorry, maybe I misunderstood your code, I'll recheck it.
2009/6/18 Xie Xiaodong
> Mark, since each of your thread runs a TestThread which implements
> runnable, those thread do not access the field or method of other threads, I
> do not think the test is multi-threaded. You could use one or two
> your BenchmarkTest class, and let more than more thread access its method
> instead.
>
>
>
> 2009/6/18 Mark Thomas
>
> Konstantin Kolinko wrote:
>> > 2009/6/18 :
>> >> Author: markt
>> >> Date: Thu Jun 18 08:32:29 2009
>> >> New Revision: 785952
>> >>
>> >> URL: http://svn.apache.org/viewvc?rev=785952&view=rev
>> >> Log:
>> >> Add some micro-benchmarks that enable the differences between the Sync
>> and ThreadLocal approach to be compared
>> >>
>> >> Added:
>> >>tomcat/trunk/test/org/apache/catalina/valves/
>> >>tomcat/trunk/test/org/apache/catalina/valves/Benchmarks.java
>> >>
>> >> (...)
>> >> +private ThreadLocal yearFormatterLocal =
>> >> +new ThreadLocal() {
>> >> +protected SimpleDateFormat initialValue() {
>> >> +return new SimpleDateFormat("");
>> >> +}
>> >> +};
>> >> +private ThreadLocal timeFormatterLocal =
>> >> +new ThreadLocal() {
>> >> +protected SimpleDateFormat initialValue() {
>> >> +return new SimpleDateFormat("hh:mm:ss");
>> >> +}
>> >> +};
>> >> +
>> >
>> > I wonder,
>> > may be we can have a single ThreadLocal that holds some object
>> > that stores all the formatters (maybe with lazy initialization),
>> > instead of wrapping each one individually?
>> >
>> > Will it make some difference?
>>
>> Don't know. You could always add your own test to the benchmarks and find
>> out :)
>>
>> Mark
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>
>
> --
> Sincerely yours and Best Regards,
> Xie Xiaodong
>
--
Sincerely yours and Best Regards,
Xie Xiaodong
svn commit: r786124 - /tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
Author: fhanik
Date: Thu Jun 18 15:27:55 2009
New Revision: 786124
URL: http://svn.apache.org/viewvc?rev=786124&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47389
patch provided by Keiichi Fujino
Modified:
tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
Modified: tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java?rev=786124&r1=786123&r2=786124&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/ha/session/DeltaManager.java Thu Jun
18 15:27:55 2009
@@ -1435,10 +1435,12 @@
// use container maxInactiveInterval so that session will expire
correctly in case of primary transfer
session.setMaxInactiveInterval(getMaxInactiveInterval());
session.access();
-if(notifySessionListenersOnReplication)
+if(notifySessionListenersOnReplication) {
session.setId(msg.getSessionID());
-else
+} else {
session.setIdInternal(msg.getSessionID());
+add(session);
+}
session.resetDeltaRequest();
session.endAccess();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47389] DeltaManager doesn't do the session replication. (notifySessionListenersOnReplication=false)
https://issues.apache.org/bugzilla/show_bug.cgi?id=47389 Filip Hanik changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Filip Hanik 2009-06-18 08:31:02 PST --- Fixed in http://svn.apache.org/viewvc?rev=786124&view=rev Backport proposed for 6.0 Many thanks for the patch! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r786125 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: fhanik Date: Thu Jun 18 15:31:13 2009 New Revision: 786125 URL: http://svn.apache.org/viewvc?rev=786125&view=rev Log: patch-proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=786125&r1=786124&r2=786125&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jun 18 15:31:13 2009 @@ -285,3 +285,8 @@ +1: kkolinko -1: +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47389 + http://svn.apache.org/viewvc?rev=786124&view=rev + +1: fhanik + -1: + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r785952 - in /tomcat/trunk/test/org/apache/catalina/valves: ./ Benchmarks.java
On 18/06/2009, Mark Thomas wrote: > Tim Funk wrote: > > I think this needs to be volatile ? > > In (GetDateBenchmarkTest) > >> +private long currentMillis = 0; > > > > Same for (in TimeDateElementBenchmarkTest) > >> +private Date currentDate = null; > > > > Of course - since the test is single threaded - it doesn't really matter. > > > The test should be multi-threaded unless I got something badly wrong. I'll > double check. > > Making those volatile gets them closer to the real code. I doubt it will > make a > difference but worth changing to be sure. You never know with these things. The field GetDateBenchmarkTest.currentDate is set in a synch. block in doSynch(), but for the return it is fetched outside the synch. block - so it could potentially be changed by another thread. Also if the synch. block is not entered, the thread might not see the correct version of the field as there is no synch. on the read. Similarly in TimeDateElementBenchmarkTest.getDateSync() - although the field is volatile, it is set in the synch. block but fetched for the return outside the block. If it is intended to allow currentDate to be updated by another thread before the return, then the field needs to be volatile. Otherwise the return value needs to be established in the synch. block. > Mark > > > > > > -Tim > > > > ma...@apache.org wrote: > >> Author: markt > >> Date: Thu Jun 18 08:32:29 2009 > >> New Revision: 785952 > >> > >> URL: http://svn.apache.org/viewvc?rev=785952&view=rev > >> Log: > >> Add some micro-benchmarks that enable the differences between the Sync > >> and ThreadLocal approach to be compared > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r785952 - in /tomcat/trunk/test/org/apache/catalina/valves: ./ Benchmarks.java
On 18/06/2009, sebb wrote: > On 18/06/2009, Mark Thomas wrote: > > Tim Funk wrote: > > > I think this needs to be volatile ? > > > In (GetDateBenchmarkTest) > > >> +private long currentMillis = 0; > > > > > > Same for (in TimeDateElementBenchmarkTest) > > >> +private Date currentDate = null; > > > > > > Of course - since the test is single threaded - it doesn't really > matter. > > > > > > The test should be multi-threaded unless I got something badly wrong. I'll > > double check. > > > > Making those volatile gets them closer to the real code. I doubt it will > make a > > difference but worth changing to be sure. You never know with these > things. > > > The field GetDateBenchmarkTest.currentDate is set in a synch. block in > doSynch(), but for the return it is fetched outside the synch. block - > so it could potentially be changed by another thread. Also if the > synch. block is not entered, the thread might not see the correct > version of the field as there is no synch. on the read. > > Similarly in TimeDateElementBenchmarkTest.getDateSync() - although the > field is volatile, it is set in the synch. block but fetched for the > return outside the block. > > If it is intended to allow currentDate to be updated by another thread > before the return, then the field needs to be volatile. Otherwise the > return value needs to be established in the synch. block. > Oops, forgot to mention - there are only 5 threads in the test; it might be useful to try tests with increasing numbers of threads to see if the relative numbers change. > > Mark > > > > > > > > > > -Tim > > > > > > ma...@apache.org wrote: > > >> Author: markt > > >> Date: Thu Jun 18 08:32:29 2009 > > >> New Revision: 785952 > > >> > > >> URL: http://svn.apache.org/viewvc?rev=785952&view=rev > > >> Log: > > >> Add some micro-benchmarks that enable the differences between the Sync > > >> and ThreadLocal approach to be compared > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 6 distro on maven repository?
Is the Tomcat 6 zip on the a repository somewhere? maven.org has the 5.5.23 distro up : http://repo1.maven.org/maven2/tomcat/apache-tomcat/5.5.23/ Filip Hanik - Dev Lists wrote: I've uploaded 6.0.20 jars today, they will sync out shortly Filip Tom Cunningham wrote: Is there a public maven repository with a recent version of Tomcat 6 anywhere? We're developing a Tomcat bundle for Apache jUDDI and we're looking to upgrade our bundle from Tomcat 5.5->6.0. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r786159 - /tomcat/trunk/modules/bayeux/webapps/cometd/examples/simplechat/ticker.html
Author: fhanik
Date: Thu Jun 18 16:57:17 2009
New Revision: 786159
URL: http://svn.apache.org/viewvc?rev=786159&view=rev
Log:
Fix demo
Modified:
tomcat/trunk/modules/bayeux/webapps/cometd/examples/simplechat/ticker.html
Modified:
tomcat/trunk/modules/bayeux/webapps/cometd/examples/simplechat/ticker.html
URL:
http://svn.apache.org/viewvc/tomcat/trunk/modules/bayeux/webapps/cometd/examples/simplechat/ticker.html?rev=786159&r1=786158&r2=786159&view=diff
==
--- tomcat/trunk/modules/bayeux/webapps/cometd/examples/simplechat/ticker.html
(original)
+++ tomcat/trunk/modules/bayeux/webapps/cometd/examples/simplechat/ticker.html
Thu Jun 18 16:57:17 2009
@@ -26,8 +26,17 @@
dojo.require("dojox.cometd");
+dojo.addOnLoad(function() {
+ dojox.cometd.init("/cometd/cometd");
+ dojox.cometd.startBatch();
+ dojox.cometd.subscribe("/stock/GOOG", onMsgEvent);
+ dojox.cometd.subscribe("/stock/YHOO", onMsgEvent);
+ dojox.cometd.subscribe("/stock/SPRG", onMsgEvent);
+ dojox.cometd.endBatch();
+});
+
+
dojo.addOnUnload(function() {
- dojox.cometd.init("/cometd/cometd");
dojox.cometd.startBatch();
dojox.cometd.unsubscribe("/stock/GOOG", this,"");
dojox.cometd.unsubscribe("/stock/YHOO", this,"");
@@ -36,14 +45,6 @@
});
-dojo.addOnLoad(function() {
- dojox.cometd.init("/cometd/cometd");
- dojox.cometd.startBatch();
- dojox.cometd.subscribe("/stock/GOOG", onMsgEvent);
- dojox.cometd.subscribe("/stock/YHOO", onMsgEvent);
- dojox.cometd.subscribe("/stock/SPRG", onMsgEvent);
- dojox.cometd.endBatch();
-});
function subscribe(box, symbol) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47308] Cannot join in the cluster membership.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47308 Filip Hanik changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Filip Hanik 2009-06-18 10:02:35 PST --- Fixed in trunk, simple revert of previous commit proposed for 6.0 to go back to previous behavior -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r786163 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: fhanik
Date: Thu Jun 18 17:02:44 2009
New Revision: 786163
URL: http://svn.apache.org/viewvc?rev=786163&view=rev
Log:
patch to revert previous commit
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=786163&r1=786162&r2=786163&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Jun 18 17:02:44 2009
@@ -290,3 +290,21 @@
+1: fhanik
-1:
+* Fix bug (revert commit)
+ https://issues.apache.org/bugzilla/show_bug.cgi?id=47308
+Index: java/org/apache/catalina/tribes/membership/McastServiceImpl.java
+===
+--- java/org/apache/catalina/tribes/membership/McastServiceImpl.java
(revision 785814)
java/org/apache/catalina/tribes/membership/McastServiceImpl.java
(working copy)
+@@ -199,7 +199,7 @@
+ } else {
+ socket = new MulticastSocket(port);
+ }
+-socket.setLoopbackMode(true); //hint that we don't need loop back
messages
++socket.setLoopbackMode(false);
+ if (mcastBindAddress != null) {
+ if(log.isInfoEnabled())
+ log.info("Setting multihome multicast interface to:"
+mcastBindAddress);
+
+ +1: fhanik
+ -1:
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Modified dist.xml to produce platform native packages
Mark Thomas wrote: Mladen Turk wrote: (I'm not even convinced we absolutely need CR-LF line endings). The reason is that some platforms have limited default tar implementation like Solaris (especially for long file names and paths). I see where you are coming from but I think the line ending changes should stay. I suppose the .sh files have LF line endings even in .zip, and those are the only one critical. So, to find a common denominator, how about: apache-tomcat-0.0.0.zip apache-tomcat-0.0.0-windows-x86.zip apache-tomcat-0.0.0-windows-x64.zip apache-tomcat-0.0.0-windows-i64.zip The latest three would contain everything from apache-tomcat-0.0.0.zip + service wrapper + native. +1. If we get feedback from users that suggests changes we can re-evaluate. OK, I'll modify the trunk dist.xml and prepare 6.0 and 5.5 patches and propose a backport. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r786165 - in /tomcat/trunk: java/org/apache/catalina/tribes/membership/McastService.java java/org/apache/catalina/tribes/membership/McastServiceImpl.java webapps/docs/config/cluster-member
Author: fhanik
Date: Thu Jun 18 17:08:38 2009
New Revision: 786165
URL: http://svn.apache.org/viewvc?rev=786165&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47308
Patch provided by Keiichi Fujino with one change, default is false
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
tomcat/trunk/webapps/docs/config/cluster-membership.xml
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java?rev=786165&r1=786164&r2=786165&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/membership/McastService.java
Thu Jun 18 17:08:38 2009
@@ -245,6 +245,9 @@
properties.setProperty("recoverySleepTime",
String.valueOf(recoverySleepTime));
}
+public void setLocalLoopbackDisabled(boolean localLoopbackDisabled) {
+
properties.setProperty("localLoopbackDisabled",String.valueOf(localLoopbackDisabled));
+}
/**
* @deprecated use getPort()
@@ -383,7 +386,8 @@
ttl,
soTimeout,
this,
-this);
+this,
+
Boolean.valueOf(properties.getProperty("localLoopbackDisabled","false")).booleanValue());
String value = properties.getProperty("recoveryEnabled","true");
boolean recEnabled = Boolean.valueOf(value).booleanValue() ;
impl.setRecoveryEnabled(recEnabled);
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java?rev=786165&r1=786164&r2=786165&view=diff
==
---
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
(original)
+++
tomcat/trunk/java/org/apache/catalina/tribes/membership/McastServiceImpl.java
Thu Jun 18 17:08:38 2009
@@ -148,6 +148,11 @@
protected ExecutorService executor = new ThreadPoolExecutor(0, 2, 0L,
TimeUnit.MILLISECONDS, new LinkedBlockingQueue());
/**
+ * disable/enable local loopback message
+ */
+protected boolean localLoopbackDisabled = false;
+
+/**
* Create a new mcast service impl
* @param member - the local member
* @param sendFrequency - the time (ms) in between pings sent out
@@ -156,6 +161,7 @@
* @param bind - the bind address (not sure this is used yet)
* @param mcastAddress - the mcast address
* @param service - the callback service
+ * @param disableLoopbackMode - disable loopbackMode
* @throws IOException
*/
public McastServiceImpl(
@@ -168,7 +174,8 @@
int ttl,
int soTimeout,
MembershipListener service,
-MessageListener msgservice)
+MessageListener msgservice,
+boolean localLoopbackDisabled)
throws IOException {
this.member = member;
this.address = mcastAddress;
@@ -180,6 +187,7 @@
this.service = service;
this.msgservice = msgservice;
this.sendFrequency = sendFrequency;
+this.localLoopbackDisabled = localLoopbackDisabled;
init();
}
@@ -213,7 +221,7 @@
} else {
socket = new MulticastSocket(port);
}
-socket.setLoopbackMode(true); //hint that we don't need loop back
messages
+socket.setLoopbackMode(localLoopbackDisabled); //hint if we want
disable loop back(local machine) messages
if (mcastBindAddress != null) {
if(log.isInfoEnabled())
log.info("Setting multihome multicast interface to:"
+mcastBindAddress);
Modified: tomcat/trunk/webapps/docs/config/cluster-membership.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/cluster-membership.xml?rev=786165&r1=786164&r2=786165&view=diff
==
--- tomcat/trunk/webapps/docs/config/cluster-membership.xml (original)
+++ tomcat/trunk/webapps/docs/config/cluster-membership.xml Thu Jun 18 17:08:38
2009
@@ -147,6 +147,14 @@
The default is 5000 (5 seconds).
+
+
+
+ Membership uses multicast, it will call
java.net.MulticastSocket.setLoopbackMode(localLoopbackDisabled).
+ When localLoopbackDisabled==true multicast messages will
not reach other nodes on the same local machine.
+ The default is false.
+
+
-
DO NOT REPLY [Bug 47342] ReplicatedContext#start throws NullPointerException.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47342 --- Comment #1 from Filip Hanik 2009-06-18 11:16:14 PST --- I'm unable to replicate your use case, mostly cause it seems as the className attribute is ignored on the conf/context.xml element -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Modified dist.xml to produce platform native packages
Hi, Mark Thomas schrieb: > +1. If we get feedback from users that suggests changes we can re-evaluate. I got in the past every now and then feedbacks from users who wanted to upgrade TC from a previous version: they were really confused by the single packages, and always asking 'what do I really need to download now?' ... Personally I would prefer something like the MSYS or Cygwin installer: one executable (I think this could / should even be written in Java) which then downloads the required packages from the mirrors depending on the platform it runs on, and depending on choices the user selects. This way you split into as many packages as you think makes sense while finally hiding this from the user who always only needs to download the installer - and perhaps its even more simple if we would have a installer applet which launches via Java Webstart... Günter. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Modified dist.xml to produce platform native packages
Guenter Knauf wrote: Personally I would prefer something like the MSYS or Cygwin installer: one executable (I think this could / should even be written in Java) One thing I hate with Cygwin is it's installer, and with Mingw I really have no clue what to download from the hundred or so things on the sf site, so it's all about taste ;) which then downloads the required packages from the mirrors depending on the platform it runs on, and depending on choices the user selects. This way you split into as many packages as you think makes sense while finally hiding this from the user who always only needs to download the installer - and perhaps its even more simple if we would have a installer applet which launches via Java Webstart... This is just one view on the subject. There are users that create their own packages, embed Tomcat, install on server farm and generally do a whole sort of things. BTW, what you are suggesting can be done with Maven, so there's no reason for some generic installer. I think someone is even maintaining the Maven repository. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r785952 - in /tomcat/trunk/test/org/apache/catalina/valves: ./ Benchmarks.java
I think the entire Benchmark test is wrong.
I'm not sure what we are trying to do in this test, in my mind we are
proving nothing with this test :)
The thread safety in AccessLogValve is the fact that the formatters are
not thread safe and can yield some funky dates showing up.
And in the ideal solution its just not to wrap everything up in a
synchronized statement.
The other thread safety issue in AccessLogValve is the the rotation of
files, since it seems as one thread can close the file
There are more efficient AccessLogValve, instead of doing all this
comparison crap on every single request, and writing to the file on
every single request.
An example:
1. single back thread updates the currentDateString once a second.
2. Add the log entries to the queue, who writes out the buffer once a
second.
If you don't want a background thread, then still the stuff going on in
the Benchmark test is not needed, and the bench mark is far from
efficient and there are other ways of doing it much better than we have
today.
Writing to a file the way we do it is synchronized, anyway, so the goal
was only to achieve non funky dates.
PrintWriter.java
public void println(String x) {
synchronized (lock) {
print(x);
println();
}
}
Filip
sebb wrote:
On 18/06/2009, sebb wrote:
On 18/06/2009, Mark Thomas wrote:
> Tim Funk wrote:
> > I think this needs to be volatile ?
> > In (GetDateBenchmarkTest)
> >> +private long currentMillis = 0;
> >
> > Same for (in TimeDateElementBenchmarkTest)
> >> +private Date currentDate = null;
> >
> > Of course - since the test is single threaded - it doesn't really matter.
>
>
> The test should be multi-threaded unless I got something badly wrong. I'll
> double check.
>
> Making those volatile gets them closer to the real code. I doubt it will
make a
> difference but worth changing to be sure. You never know with these things.
The field GetDateBenchmarkTest.currentDate is set in a synch. block in
doSynch(), but for the return it is fetched outside the synch. block -
so it could potentially be changed by another thread. Also if the
synch. block is not entered, the thread might not see the correct
version of the field as there is no synch. on the read.
Similarly in TimeDateElementBenchmarkTest.getDateSync() - although the
field is volatile, it is set in the synch. block but fetched for the
return outside the block.
If it is intended to allow currentDate to be updated by another thread
before the return, then the field needs to be volatile. Otherwise the
return value needs to be established in the synch. block.
Oops, forgot to mention - there are only 5 threads in the test; it
might be useful to try tests with increasing numbers of threads to see
if the relative numbers change.
> Mark
>
>
> >
> > -Tim
> >
> > ma...@apache.org wrote:
> >> Author: markt
> >> Date: Thu Jun 18 08:32:29 2009
> >> New Revision: 785952
> >>
> >> URL: http://svn.apache.org/viewvc?rev=785952&view=rev
> >> Log:
> >> Add some micro-benchmarks that enable the differences between the Sync
> >> and ThreadLocal approach to be compared
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release JDBC Pool module v1.0.4
So now that we've clarified that NOTICE and LICENSE covers the entire release as an entity, my vote [X] STABLE - I couldn't find any bugs Filip Filip Hanik - Dev Lists wrote: Cleaned up and fixed. The release is located here: http://people.apache.org/~fhanik/jdbc-pool/v1.0.4/ [ ] STABLE - I couldn't find any bugs [ ] BETA - I found some bugs but not critical [ ] BROKEN - I found some show stoppers Any comments ? Thanks, Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
className in conf/context.xml
is no longer being picked up, at least not in my test. I think it's related to the deploy refactor that has been going on, possibly related to https://issues.apache.org/bugzilla/show_bug.cgi?id=47343 Filip - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release JDBC Pool module v1.0.4
On 19/06/2009, Filip Hanik - Dev Lists wrote: > So now that we've clarified that NOTICE and LICENSE covers the entire > release as an entity, No idea what you mean by that, but anyway: As I have written several times before, the NOTICE file is incorrect. This applies to the version in the SVN tag JDBC_POOL_1_0_4 as well as the version in the archives. Please read: http://www.apache.org/dev/release.html#notice-required IMO, the proposed release does not meet the ASF requirements because: - incorrect NOTICE file - no pure source release (which is what is supposed to be voted on) - no test code in the release > my vote > [X] STABLE - I couldn't find any bugs > Filip > > > Filip Hanik - Dev Lists wrote: > > > Cleaned up and fixed. > > > > The release is located here: > > http://people.apache.org/~fhanik/jdbc-pool/v1.0.4/ > > > > > > [ ] STABLE - I couldn't find any bugs > > [ ] BETA - I found some bugs but not critical > > [ ] BROKEN - I found some show stoppers > > > > > > Any comments ? > > > > Thanks, > > Filip > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47342] ReplicatedContext#start throws NullPointerException.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47342
--- Comment #2 from Keiichi Fujino 2009-06-18
23:56:22 PST ---
(In reply to comment #1)
> I'm unable to replicate your use case, mostly cause it seems as the className
> attribute is ignored on the conf/context.xml element
I'm so sorry in the insufficient explanation.
To reproduce this bug
It is necessary to set ReplicatedContext to <>.xml of
conf/Catalina/localhost/directory.
It is not conf/context.xml.
IMHO,
I think that className attribute is ignored in conf/context.xml.
Because
context instance is created by deploy method of HostConfig.
and
The ContextRuleSet created by ContextConfig(parse conf/context.xml) is as
follows.
RuleSet contextRuleSet = new ContextRuleSet("", false);
When boolean of the second argument is false, context instance is not created
by Digester.
As a Result,
ObjectCreateRule to className attribute of Context is not added.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
