You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(68) |
Dec
(77) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(75) |
Feb
(84) |
Mar
(89) |
Apr
(96) |
May
(52) |
Jun
(73) |
Jul
(99) |
Aug
(46) |
Sep
(40) |
Oct
(46) |
Nov
(45) |
Dec
(25) |
2004 |
Jan
(13) |
Feb
(74) |
Mar
(40) |
Apr
(18) |
May
(31) |
Jun
(1) |
Jul
(16) |
Aug
(1) |
Sep
(21) |
Oct
(19) |
Nov
(10) |
Dec
(16) |
2005 |
Jan
(4) |
Feb
(12) |
Mar
(46) |
Apr
(33) |
May
(64) |
Jun
(1) |
Jul
(60) |
Aug
(31) |
Sep
(26) |
Oct
(24) |
Nov
(37) |
Dec
(10) |
2006 |
Jan
(3) |
Feb
(31) |
Mar
(122) |
Apr
(22) |
May
(4) |
Jun
|
Jul
|
Aug
(2) |
Sep
(4) |
Oct
(8) |
Nov
(3) |
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(8) |
From: <WebMacro@Stolsvik.com> - 2006-04-04 09:40:38
|
On Tue, 4 Apr 2006, Endre St=F8lsvik wrote: | On Mon, 3 Apr 2006, Keats Kirsch wrote: |=20 | | Endre St=F8lsvik wrote: | |=20 | | > I personally use log4j for our server, so log4j would in theory sui= t me | | > totally nice, but considering that there are both log4j and the now= rather | | > prevalent jsr 47 (java.util.logging) and some other fringe stuff, i= t seems | | > slightly backwards to go with one specific system. | | >=20 | | > Regards, | | > Endre | | > =20 | | I agree. I think we should look at the JCL | | (http://jakarta.apache.org/commons/logging/) since it already provide= s | | adapters for java.logging and Log4J, etc. |=20 | And again, SLF4J. | http://www.slf4j.org/ |=20 | This uses a very different "resolving" than clogging (=3D=3Djcl), in th= at you=20 | actually include a specific implementation of the "logging facade": you= =20 | simply add one of several jars to the classpath, e.g. a slf4j-log4j.jar= ,=20 | or slf4j-jsr47.jar, or a simple slf4j-stderr.jar. (Names have been fake= d,=20 | to protect me from actually having to look them up)=20 | Ceki G=FClc=FC (the founder of log4j) started this as a reaction to l= ots of=20 | problems with the clogging-paradigm, that has to do with classloaders i= n=20 | multi-cl systems, _typically_ servlet containers, tomcat. Since slfj4 u= ses=20 | a _static_ linking, such problems are thus avoided. Reading this message, I find that I sound like an evangelist. I'm not. I just wanted to point out that there are _two_ solutions to the=20 underlying problem. The oldest is commons logging / jcl / "clogging". Thi= s=20 doesn't come without problems, in particular in servlet container=20 scenarios, and to address these problems, slf4j has been developed. These= =20 are "very competing" in how they solve the problem at hand. I'm not sure which one is best - I don't think there is a clear-cut=20 answer, and the answer will probably be different for different settings.= =20 One should be sure that one actually _understand_ the two solutions and=20 their problems before blasting out with "obviously slf4j is best, always!= "=20 or the opposite. But I do think that both solutions must be known by the community befor= e=20 a decision is made! Regards, Endre. |
From: <WebMacro@Stolsvik.com> - 2006-04-04 09:30:19
|
On Mon, 3 Apr 2006, Keats Kirsch wrote: | Endre St=F8lsvik wrote: |=20 | > I personally use log4j for our server, so log4j would in theory suit = me | > totally nice, but considering that there are both log4j and the now r= ather | > prevalent jsr 47 (java.util.logging) and some other fringe stuff, it = seems | > slightly backwards to go with one specific system. | >=20 | > Regards, | > Endre | > =20 | I agree. I think we should look at the JCL | (http://jakarta.apache.org/commons/logging/) since it already provides | adapters for java.logging and Log4J, etc. And again, SLF4J. http://www.slf4j.org/ This uses a very different "resolving" than clogging (=3D=3Djcl), in that= you=20 actually include a specific implementation of the "logging facade": you=20 simply add one of several jars to the classpath, e.g. a slf4j-log4j.jar,=20 or slf4j-jsr47.jar, or a simple slf4j-stderr.jar. (Names have been faked,= =20 to protect me from actually having to look them up)=20 Ceki G=FClc=FC (the founder of log4j) started this as a reaction to lot= s of=20 problems with the clogging-paradigm, that has to do with classloaders in=20 multi-cl systems, _typically_ servlet containers, tomcat. Since slfj4 use= s=20 a _static_ linking, such problems are thus avoided. Regards, Endre. |
From: Keats K. <ke...@xa...> - 2006-04-03 17:03:18
|
Endre Stølsvik wrote: >I personally use log4j for our server, so log4j would in theory suit me >totally nice, but considering that there are both log4j and the now rather >prevalent jsr 47 (java.util.logging) and some other fringe stuff, it seems >slightly backwards to go with one specific system. > >Regards, >Endre > > I agree. I think we should look at the JCL (http://jakarta.apache.org/commons/logging/) since it already provides adapters for java.logging and Log4J, etc. Keats |
From: <WebMacro@Stolsvik.com> - 2006-04-03 10:40:01
|
On Mon, 3 Apr 2006, Sven Schliesing wrote: | So we see no vehement protest against using log4j, right? .. But maybe through commons logging? (or SLF4J) I personally use log4j for our server, so log4j would in theory suit me totally nice, but considering that there are both log4j and the now rather prevalent jsr 47 (java.util.logging) and some other fringe stuff, it seems slightly backwards to go with one specific system. Regards, Endre |
From: Sven S. <sv...@sc...> - 2006-04-03 08:57:43
|
So we see no vehement protest against using log4j, right? Is there a roadmap for upcoming releases? Sven Endre Stølsvik wrote: > Yes! > > Clogging, or the new Ceki-driven SLF4J, og just log4j directly. |
From: <WebMacro@Stolsvik.com> - 2006-04-03 08:47:34
|
On Fri, 31 Mar 2006, Keats Kirsch wrote: | I don't see the cause of this from a quick inspection, however it does appear | that the LogFile.log method is not thread-safe, given Endre's recent | revelation about the SimpleDateFormat. It isn't the nice "ClockThread" that was ripped out? Maybe it was ripped out, but the using code wasn't fixt up? | | Personally, I'd vote for ripping out the WM logging completely and using a | better framework like Log4J. Yes! Clogging, or the new Ceki-driven SLF4J, og just log4j directly. Watch out for the getting of Loggers (static - not on every instance and definately not on every log-line), and always implement the if (log.isDebugEnabled()) "wrapper". The reason for commenting on it, is that I do think I've seen places where this is totally wrong within WM. Endre. |
From: Marcello H <mar...@gm...> - 2006-03-31 21:19:28
|
Dotay I also tried something with log4j because I was mentioned in the properties-file. However it didn't work for me, and I didn't had a lot of time to spend on i= t. Has anyone succeeded in using log4j, then let him (or her!) speak...... -Marcel- 2006/3/31, Sven Schliesing <sv...@sc...>: > !vote > It was quite a pain when I tried to implement a wrapper for log4j. After > giving up I wondered why webmacro doesn't use log4j, commons-logging or > something similar. > > Sven > > Keats Kirsch wrote: > > I don't see the cause of this from a quick inspection, however it does > > appear that the LogFile.log method is not thread-safe, given Endre's > > recent revelation about the SimpleDateFormat. > > > > Personally, I'd vote for ripping out the WM logging completely and usin= g > > a better framework like Log4J. > > > > Keats > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Webmacro-user mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-user > |
From: Sven S. <sv...@sc...> - 2006-03-31 16:39:33
|
!vote It was quite a pain when I tried to implement a wrapper for log4j. After giving up I wondered why webmacro doesn't use log4j, commons-logging or something similar. Sven Keats Kirsch wrote: > I don't see the cause of this from a quick inspection, however it does > appear that the LogFile.log method is not thread-safe, given Endre's > recent revelation about the SimpleDateFormat. > > Personally, I'd vote for ripping out the WM logging completely and using > a better framework like Log4J. > > Keats |
From: Keats K. <ke...@xa...> - 2006-03-31 16:33:59
|
I don't see the cause of this from a quick inspection, however it does appear that the LogFile.log method is not thread-safe, given Endre's recent revelation about the SimpleDateFormat. Personally, I'd vote for ripping out the WM logging completely and using a better framework like Log4J. Keats Mike Weerdenburg - de Bruin (Werk) wrote: >Hello Marcel, > >I had a look at my logfile... and I have the same problem! > >It looks like it logs with the latest startup time! > >These logs are from today... but the timestamp is from yesterday! >30-03-2006 14:47:43.812 >30-03-2006 14:47:43.812 >30-03-2006 14:47:43.812 >... Etc. etc. > > >I have done some quick testing: > >It seems like Clock.java doesn't return the correct value's. >In particular: System.currentTimeMillis() > >System.out: >------------ >System.currentTimeMillis() 1143795904156 >time 1143795904156 >TIME 1143795880312 >TIME - time -23844 >< 1000 > >System.currentTimeMillis() 1143795904156 >time 1143795904156 >TIME 1143795880312 >TIME - time -23844 >< 1000 > >System.currentTimeMillis() 1143795904156 >time 1143795904156 >TIME 1143795880312 >TIME - time -23844 >< 1000 >... Etc. etc. > >I don't have the time to sort this problem out... >But I hope it helps someone else to solve this problem! > >Greetings, >Mike > >Atatchments: >LogFile.java (Latest version! With LogFilePerDay etc.) >Clock.java (With some System.out.println's for debugging) > > >-----Oorspronkelijk bericht----- >Van: web...@li... >[mailto:web...@li...] Namens Marcello H >Verzonden: vrijdag 31 maart 2006 10:14 >Aan: web...@li... >Onderwerp: ***SPAM***[WebMacro-user] wm.log time stamp broken? > >I checked out the cvs-code this week, and found out that the time stamp >in the wm-file is almost the same on ervy hit from the same logger. > >(I must say, i didn't look at this particular thing in detail lately...) > >Do other people experience this also? > >Greetings, >Marcel Huijkman > > > > |
From: Keats K. <ke...@xa...> - 2006-03-31 16:05:20
|
Marcello H wrote: >If I just replace concurrent.jar with backport-util-concurrent-2.1.jar >it won't start my application. > > Yeah, you have to change the package name in the include. Also there are a few missing classes. I have a patched version running on my box, but I'm not sure if I should commit it to CVS. Any thoughts? |
From: Mike W. - de B. \(Werk\) <M.W...@tr...> - 2006-03-31 09:12:21
|
Hello Marcel, I had a look at my logfile... and I have the same problem! It looks like it logs with the latest startup time! These logs are from today... but the timestamp is from yesterday! 30-03-2006 14:47:43.812 30-03-2006 14:47:43.812 30-03-2006 14:47:43.812 ... Etc. etc. I have done some quick testing: It seems like Clock.java doesn't return the correct value's. In particular: System.currentTimeMillis() System.out: ------------ System.currentTimeMillis() 1143795904156 time 1143795904156 TIME 1143795880312 TIME - time -23844 < 1000 System.currentTimeMillis() 1143795904156 time 1143795904156 TIME 1143795880312 TIME - time -23844 < 1000 System.currentTimeMillis() 1143795904156 time 1143795904156 TIME 1143795880312 TIME - time -23844 < 1000 ... Etc. etc. I don't have the time to sort this problem out... But I hope it helps someone else to solve this problem! Greetings, Mike Atatchments: LogFile.java (Latest version! With LogFilePerDay etc.) Clock.java (With some System.out.println's for debugging) -----Oorspronkelijk bericht----- Van: web...@li... [mailto:web...@li...] Namens Marcello H Verzonden: vrijdag 31 maart 2006 10:14 Aan: web...@li... Onderwerp: ***SPAM***[WebMacro-user] wm.log time stamp broken? I checked out the cvs-code this week, and found out that the time stamp in the wm-file is almost the same on ervy hit from the same logger. (I must say, i didn't look at this particular thing in detail lately...) Do other people experience this also? Greetings, Marcel Huijkman ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting = language that extends applications into web and mobile media. Attend the live = webcast and join the prime developer group breaking into this new coding = territory! http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642 _______________________________________________ Webmacro-user mailing list Web...@li... https://lists.sourceforge.net/lists/listinfo/webmacro-user |
From: Marcello H <mar...@gm...> - 2006-03-31 08:13:45
|
I checked out the cvs-code this week, and found out that the time stamp in the wm-file is almost the same on ervy hit from the same logger. (I must say, i didn't look at this particular thing in detail lately...) Do other people experience this also? Greetings, Marcel Huijkman |
From: Marcello H <mar...@gm...> - 2006-03-31 08:06:36
|
If I just replace concurrent.jar with backport-util-concurrent-2.1.jar it won't start my application. java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/ConcurrentHashMap at org.webmacro.Broker.<init>(Broker.java:86) at org.webmacro.Broker.<init>(Broker.java:119) at org.webmacro.Broker.getBroker(Broker.java:462) at org.webmacro.WM.<init>(WM.java:66) at prg.Wsf.init(Wsf.java:153) 2006/3/30, Keats Kirsch <ke...@xa...>: > Doug Lea's Web site says that the ClockDaemon will be released as part > of a separate package, since it has no analog in the JDK 1.5. In the > meantime, I will look at copying the class. > > Keats > > Keats Kirsch wrote: > > > Make sure the ant-junit.jar is in your classpath. Ant really is great > > -- once you get it working. > > > > I found a problem with using the backported concurrency classes. > > Apparently the did not backport the ClockDaemon class, which is used > > by the reloading cache manager. We could just incorporate a version > > of the class in WM, since it is in the public domain, but I'd like to > > find out why it wasn't ported first. I'll do some research. > > > > Keats > > > > Sven Schliesing wrote: > > > >> I seem to not getting this to work properly. I'm stuck getting this > >> message: > >> D:\workspace\webmacro\test\build.xml:29: taskdef A class needed by > >> class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask cannot > >> be found: junit/framework/Test > >> > >> It seems like Ant and me will never get friends. :) > >> Did you try running the tests with the backport, Keats? > >> > >> Sven > >> > >> Keats Kirsch wrote: > >> > >>> Thanks for giving it a shot Sven. I too always find getting the > >>> unit test configured properly to be a chore. > >>> > >>> The JUnitTask is part of a jar called ant-junit.jar that comes with > >>> the Apache Ant distro: http://ant.apache.org/bindownload.cgi > >>> > >>> Keats > >> > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > Webmacro-user mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-user > |
From: Marcello H <mar...@gm...> - 2006-03-31 07:43:00
|
Has anyone implemented log4j and if so, can you give me some hints on how to do this also? |
From: Keats K. <ke...@xa...> - 2006-03-30 15:51:51
|
Doug Lea's Web site says that the ClockDaemon will be released as part of a separate package, since it has no analog in the JDK 1.5. In the meantime, I will look at copying the class. Keats Keats Kirsch wrote: > Make sure the ant-junit.jar is in your classpath. Ant really is great > -- once you get it working. > > I found a problem with using the backported concurrency classes. > Apparently the did not backport the ClockDaemon class, which is used > by the reloading cache manager. We could just incorporate a version > of the class in WM, since it is in the public domain, but I'd like to > find out why it wasn't ported first. I'll do some research. > > Keats > > Sven Schliesing wrote: > >> I seem to not getting this to work properly. I'm stuck getting this >> message: >> D:\workspace\webmacro\test\build.xml:29: taskdef A class needed by >> class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask cannot >> be found: junit/framework/Test >> >> It seems like Ant and me will never get friends. :) >> Did you try running the tests with the backport, Keats? >> >> Sven >> >> Keats Kirsch wrote: >> >>> Thanks for giving it a shot Sven. I too always find getting the >>> unit test configured properly to be a chore. >>> >>> The JUnitTask is part of a jar called ant-junit.jar that comes with >>> the Apache Ant distro: http://ant.apache.org/bindownload.cgi >>> >>> Keats >> |
From: Keats K. <ke...@xa...> - 2006-03-30 15:19:06
|
Make sure the ant-junit.jar is in your classpath. Ant really is great -- once you get it working. I found a problem with using the backported concurrency classes. Apparently the did not backport the ClockDaemon class, which is used by the reloading cache manager. We could just incorporate a version of the class in WM, since it is in the public domain, but I'd like to find out why it wasn't ported first. I'll do some research. Keats Sven Schliesing wrote: > I seem to not getting this to work properly. I'm stuck getting this > message: > D:\workspace\webmacro\test\build.xml:29: taskdef A class needed by > class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask cannot be > found: junit/framework/Test > > It seems like Ant and me will never get friends. :) > Did you try running the tests with the backport, Keats? > > Sven > > Keats Kirsch wrote: > >> Thanks for giving it a shot Sven. I too always find getting the unit >> test configured properly to be a chore. >> >> The JUnitTask is part of a jar called ant-junit.jar that comes with >> the Apache Ant distro: http://ant.apache.org/bindownload.cgi >> >> Keats > |
From: Keats K. <ke...@xa...> - 2006-03-30 15:05:37
|
Good catch Endre! Glad I didn't go down that path yet. Perhaps we should look for an alternative date formatting system. I found something called Joda Time on SourceForge (http://www.joda.org/) that looks like it might fit the bill. From their FAQ: "The most common multi-threading mistake made by Java programmers is in the use of SimpleDateFormat. Calling its format method on a shared instance by concurrent threads can produce bizarre results. All of Joda-Time's formatting classes are thread-safe and immutable." They also claim it is faster than SimpleDateFormat. Keats Endre Stølsvik wrote: >... > >| Is (Simple)DateFormat itself completely thread-safe, by contract? > >Forgot to point out that you obvioulsy may just do both the map-lookup >_and_ the formatting within the one synch-block (but then you can forget >the benefit of ConcurrentHashMap) - or you could have a pool of each >format - say 10 instances - and actually do "connection pooling" logic. > But at that point, I do hope that more than me thinks that having "one >more cached resource" (with the synch and potential contention hit (now >both for the synch and the formatting-time), and "memory bloat") for that >amazingly little benefit (e.g. 1 ms for 40 formattings) isn't worth the >hassle? > >Add a method to dateTool that actually gives you a DateFormat back, and >javadoc both methods where the users are told to use the >DateFormat-returning one if they're about to format multiple dates in one >rendering. > >Regards, >Endre. > > |
From: <WebMacro@Stolsvik.com> - 2006-03-30 11:51:53
|
... | Is (Simple)DateFormat itself completely thread-safe, by contract? Forgot to point out that you obvioulsy may just do both the map-lookup _and_ the formatting within the one synch-block (but then you can forget the benefit of ConcurrentHashMap) - or you could have a pool of each format - say 10 instances - and actually do "connection pooling" logic. But at that point, I do hope that more than me thinks that having "one more cached resource" (with the synch and potential contention hit (now both for the synch and the formatting-time), and "memory bloat") for that amazingly little benefit (e.g. 1 ms for 40 formattings) isn't worth the hassle? Add a method to dateTool that actually gives you a DateFormat back, and javadoc both methods where the users are told to use the DateFormat-returning one if they're about to format multiple dates in one rendering. Regards, Endre. |
From: <WebMacro@Stolsvik.com> - 2006-03-30 11:22:25
|
On Wed, 29 Mar 2006, Keats Kirsch wrote: | Thanks Sven. | | I've gone through the code and found one other place where this loop could | occur; the TypeDirective. I have committed a patch for that as well. There | is currently no unit test for this directive; I'll try to add one. (Does | anybody use this?) | | It occurs to me that we are still vulnerable to infinite loops with other | Macro implementations. I noticed in the PropertyMethod class that it actually | tests if the Macro evaluates to itself. This takes us one step further, but | you could still have an infinite loop if there is a multiple class circular | reference. E.g., MacroA evals to MacroB which evals to MacroA. It's probably | not worth guarding against this somewhat arcane case. What do folks think? It is sad that WM gives this much power to the templating layer - on a philosophical level. I liked it when there wasn't even #count - you couldn't "program" i WM - as it was intentionally too limited for this - you were supposed to just lay out your already-fetched data. Other stuff has been put into WM to guard against template-writers access to "dangerous classes and methods" (java.lang.Class), but now they can take the entire WM down by executing an infinite loop. It doesn't matter for _me_, though. Regards, Endre. |
From: <WebMacro@Stolsvik.com> - 2006-03-30 11:17:11
|
On Wed, 29 Mar 2006, Alex Twisleton-Wykeham-Fiennes wrote: | On Tue 28 March 2006 10:06, Endre St=F8lsvik wrote: | > With how many threads did you test this? 1000? 100? 10? 1? And how | > "real-life" was the scenario: how many date-formattings will one | > typically do within one rendering? |=20 | Much as I hate to rise to the occasion, I'll just attempt to put this o= ne to=20 | bed. .... | This is the same as the original test, just repeated 10 times to give t= he jit=20 | time to kick in. In addition, the tests have been changed as follows:- |=20 | Creator: new SimpleDateFormat for each invocation | HashMap: using an unsynchronized HashMap for access | ConcurrentHashMap: using an unsynchronized ConcurrentHashMap for access= from=20 | the concurrent.jar shipped with webmacro (does anyone know what version= this=20 | is?) |=20 | So that deals with the JIT issues. Excellent, then the JIT-point was rather moot. (You could do System.gc()=20 inbetween each test, so that gc doesn't happen within the timed loop, and= =20 start the VM with -Xms512M -Xmx512M, so that the heap doesn't have to gro= w=20 and stabilize during the test). Then what about the multi-threading issues, and "impact"-"analysis", whic= h=20 was the main point here. Lets say that we have a template with 40 date=20 formattings in (some list?), and 75 threads are rendering this constantly= =20 100 times each - how many seconds would one _theoretically_ gain by using= =20 the cache lookuped DateFormat (from the single-threaded access numbers),=20 and how much will this really be when we count the multi-threading in? This is 7500 page renders, with 40 dates each: 300.000. (I took the 8th run, it seemed somewhat fair:) 1 "created formatting" takes 0.03882 ms 1 "cached formatting" takes 0.01305 ms 300.000 "created": 11.646 sec 300.000 "cached": 3.915 sec diff: 7.731 seconds for 7500 page renders with 40 date formattings on eac= h=20 (which is a rather large "average" number of date-renderings?) For one page, we have 40*0.03882=3D1.5528 ms, vs 0.5220 (or 7731/7500),=20 which is a ~1 ms diff. The above is _given_ that there is _no_ impact of multi-thread-access to=20 the map - which I doubt is the fact. And a sub-point here is: IF you had 40 date renderings on one page,=20 shouldn't you have created the DateFormat and put it in the context=20 anyway? Or maybe the date-tool could do that for you (return an instance)= ?=20 That would have been the fastest at any rate. Okay, but now, I'll introduce - "The Bomb" (maybe): This suddenly hit me: Is (Simple)DateFormat itself completely thread-safe, by contract? I read javadoc (1.3), and it doesn't say at all. In the code, SimpleDateFormat: public StringBuffer format(Date date, StringBuffer toAppendTo, FieldPosition pos) { // Initialize pos.beginIndex =3D pos.endIndex =3D 0; // Convert input date to time field list calendar.setTime(date); ... The last line there looks very un-promising. But the javadoc..? I then tried google, "simpledateformat thread safe": first hit: http://www-128.ibm.com/developerworks/java/library/j-jtp09263.html " How many times have you looked at the Javadoc for a class, and=20 wondered, "Is this class thread-safe?" In the absence of clear=20 documentation, readers may make bad assumptions about a class's thread=20 safety. " " As an example of this pitfall, the class java.text.SimpleDateFormat i= s=20 not thread-safe, but it wasn't until the 1.4 JDK that this was documented= =20 in the Javadoc. " And yes, javadoc 1.4: " Synchronization Date formats are not synchronized. It is recommended to create separate=20 format instances for each thread. If multiple threads access a format=20 concurrently, it must be synchronized externally. " NB: The rest of the mail was written before the above hit me! Most is=20 still valid, though - but the above should hopefully get the cache=20 removed, at any rate? |=20 | > This illustrates the point about synchs that I'm trying to make: sync= hs | > are pretty much not noticeable at all if you access them with one thr= ead | > (but there was a difference, and it was in the bad direction, right?)= . | > However, _contended_ synchs are the bad stuff. A conteded synch force= s a | > complete flush of your memory-caches (read the java spec on synch if = you | > haven't yet). On "small systems", this isn't that big a deal, as they= tend | > to a) have one CPU (thus really only one cache), and b) have coherent | > caches if they are more. On larger systems, where CPUs might be more | > independent ("NUMA"), this can be a huge overhead. |=20 | Hence the usage of ConcurrentHashMap in the updated test. Okay. But a cache lookup is a cache lookup. ConcurrencHashMap is excellent=20 stuff, admittedly. But still, what about contending threads? You stated in another mail that the hitting on the ConcurrentHashMap was=20 the one thing that used most time..? How can that be? But at any rate, couldn't you hook this stuff up with the WM-internals of= =20 caching, at least? There is already lots of things cached within WM, and = I=20 fail to see the reason for not letting this thing be a part of that=20 caching-community - enabling one to configure the sizes, type of cache,=20 and all that. WM.shutdown()/clean()/whatever() must clean these caches! |=20 | Finally, if we are going to be planning on boycotting all "hidden cache= s" of=20 | code, have you actually looked at the source code for SimpleDateFormat? Yes. I know. I don't like it, but this is in "java proper", down in the=20 core libraries, and will never be GC'ed anyway. Vector, Hashtable and=20 StringBuffer is also synchronized. They've done some weird things=20 throughout java's life. That doesn't excuse making new such things. One even more fantastic thing is the JDBC DriverManager: the=20 getConnection(...) is synchronized, and drivers actually "make contact"=20 with the database at this step (log in). And e.g. Oracle's driver in=20 certain circumstances _hangs_ till that happens - thus you whole database= =20 connectivity is _utterly blocked_ until that piece of junk releases is. Driver.connect() javadocs: * Attempts to make a database connection to the given URL. * The driver should return "null" if it realizes it is the wrong kind * of driver to connect to the given URL. This will be common, as when * the JDBC driver manager is asked to connect to a given URL it passes * the URL to each loaded driver in turn. So, _within a synchronzied call_, potentially _all_ drivers will be=20 requested to try to connect to their database, where at least on,=20 potentially several, of these driver actually will make some connection,=20 usually through TCP, to the database - where timouts and whatnot might=20 happen. This is _so amazingly braindead_ that it really can't be described in=20 harsh enough words. And this is within "java proper". But that doesn't legitimize doing new such stuff with caches and=20 synch-blocks. This just to illustrate a point. |=20 | The final thing to notice about SimpleDateFormat is that it really isn'= t a=20 | nice thing to do to your garbage collector. It really does generate a=20 | *large* number of temporary items during the initialisation of=20 | SimpleDateFormat, all of which will need garbage collecting (~40 Object= s=20 | taking up ~1k per init) . Then _don't do it_. Execute your formatting "inside", using a single-instantiated formatter,=20 or make a selection of formatters available to the thread yourself, from=20 some context-up-looked map (e.g. you fetch everything you need in _one_=20 synch block, e.g. when looking up your user-object or similar, or put it=20 in the HttpSession, or _whatever_). My point is about "innocent-looking _tools_", of which sadly the entire W= M=20 is one. But I don't see the reason to still clutter it up with even more=20 "magic stuff" that does even more magic caching and synching and whatnot. 1 _k_ per unit?! and _40_ units?! Where? But still, java is by now the cheapest language in the world to do object= =20 _creations_ in. Using the generational garbage collector (default from=20 1.3, I think, and tuned i 1.4 and each genereation up), objects that=20 immediately die, are _very_ cheap to "collect" too - the point is that=20 they _aren't_ collected (only live objects are collected by the=20 copy-collector in the first stages of GC: eden -> survivor 0 and 1) http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=3Dd= gr-lnxw01JavaUrbanLegends Check out the "escape analysis" part - now that'll be cool. .. | Looking at the initialiser makes it pretty obvious=20 | that it is designed to be initialised once and then run multiple times = as the=20 | parse() and format() methods have been designed to minimise object crea= tion=20 | and are quite streamlined whereas the creator is a bit of a beast. It even says so in the javadoc, yes. ---------- If you are formatting multiple numbers, it is more efficient to get the=20 format and use it multiple times so that the system doesn't have to fetch= =20 the information about the local language and country conventions multiple= =20 times. DateFormat df =3D DateFormat.getDateInstance(); for (int i =3D 0; i < a.length; ++i) { output.println(df.format(myDate[i]) + "; "); }=20 ----------=20 (javadoc 1.3 - Text obviously copied verbatim from NumberFormat, which=20 says the exact same thing..) Regards, Endre |
From: Lane S. <la...@op...> - 2006-03-30 02:12:22
|
Sven, junit.jar is not in your classpath. Place this jar in your ant lib folder and it will then work with all of your ant files. see http://junit.org to get the jar. Lane Sven Schliesing wrote: > I seem to not getting this to work properly. I'm stuck getting this > message: > D:\workspace\webmacro\test\build.xml:29: taskdef A class needed by > class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask cannot be > found: junit/framework/Test > > It seems like Ant and me will never get friends. :) > Did you try running the tests with the backport, Keats? > > Sven > > Keats Kirsch wrote: > >> Thanks for giving it a shot Sven. I too always find getting the unit >> test configured properly to be a chore. >> >> The JUnitTask is part of a jar called ant-junit.jar that comes with >> the Apache Ant distro: http://ant.apache.org/bindownload.cgi >> >> Keats > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Webmacro-user mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-user > > -- Kindest Regards, Lane |
From: Sven S. <sv...@sc...> - 2006-03-30 01:19:15
|
I seem to not getting this to work properly. I'm stuck getting this message: D:\workspace\webmacro\test\build.xml:29: taskdef A class needed by class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask cannot be found: junit/framework/Test It seems like Ant and me will never get friends. :) Did you try running the tests with the backport, Keats? Sven Keats Kirsch wrote: > Thanks for giving it a shot Sven. I too always find getting the unit > test configured properly to be a chore. > > The JUnitTask is part of a jar called ant-junit.jar that comes with the > Apache Ant distro: http://ant.apache.org/bindownload.cgi > > Keats |
From: Keats K. <ke...@xa...> - 2006-03-30 00:08:56
|
Thanks for giving it a shot Sven. I too always find getting the unit test configured properly to be a chore. The JUnitTask is part of a jar called ant-junit.jar that comes with the Apache Ant distro: http://ant.apache.org/bindownload.cgi Keats Sven Schliesing wrote: > I did so, and after replacing the according imports it looks ok. Would > say: my application still runs like I would expect. :) > To my shame I have to admit that I couldn't get webmacros unit-test > running. > I'm not so familiar with ant (using maven for my projects), so I can't > fix the errors that I get: > > D:\workspace\webmacro\test\build.xml:57: Could not create task or type > of type: junit. > > And after commenting in this element in test/build.xml: > <!-- > <taskdef name="junit" > classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTask"> > <classpath refid="class.path"/> > </taskdef> > --> > I get > D:\workspace\webmacro\test\build.xml:29: taskdef A class needed by > class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask cannot be > found: junit/framework/Test > > > Maybe it's just too late this evening... > > Greets Sven |
From: Sven S. <sv...@sc...> - 2006-03-29 22:56:20
|
I did so, and after replacing the according imports it looks ok. Would say: my application still runs like I would expect. :) To my shame I have to admit that I couldn't get webmacros unit-test running. I'm not so familiar with ant (using maven for my projects), so I can't fix the errors that I get: D:\workspace\webmacro\test\build.xml:57: Could not create task or type of type: junit. And after commenting in this element in test/build.xml: <!-- <taskdef name="junit" classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTask"> <classpath refid="class.path"/> </taskdef> --> I get D:\workspace\webmacro\test\build.xml:29: taskdef A class needed by class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask cannot be found: junit/framework/Test Maybe it's just too late this evening... Greets Sven |
From: Keats K. <ke...@xa...> - 2006-03-29 21:29:19
|
Alex Twisleton-Wykeham-Fiennes wrote: >the concurrent.jar shipped with webmacro (does anyone know what version this >is?) > Comparing the time stamps on the class files to the release notes, it appears that we are somewhere between 1.3.1 and 1.3.2. Doug Lea is recommending that everyone switch to the "backport" version (more JDK 1.5/JSR 166 compatible) which is at version 2.1 currently: http://dcl.mathcs.emory.edu/util/backport-util-concurrent/ I'll try downloading and testing with this version. If anyone else can do that as well I'd appreciate it. Keats |