- logback-dev - mailman3.qos.ch

svn commit: r2298 - in logback-demo/trunk/src/main: java/ch/qos/logback/demo java/ch/qos/logback/demo/login java/ch/qos/logback/demo/prime resources resources/parts webapp/WEB-INF
by noreply.ceki＠qos.ch 21 Jun '09

21 Jun '09

Author: ceki Date: Sun Jun 21 16:56:45 2009 New Revision: 2298 Added: logback-demo/trunk/src/main/java/ch/qos/logback/demo/UserServletFilter.java Modified: logback-demo/trunk/src/main/java/ch/qos/logback/demo/login/LoginAction.java logback-demo/trunk/src/main/java/ch/qos/logback/demo/prime/PrimeAction.java logback-demo/trunk/src/main/resources/logback.xml logback-demo/trunk/src/main/resources/parts/sifting.xml logback-demo/trunk/src/main/webapp/WEB-INF/web.xml Log: - update the demo Added: logback-demo/trunk/src/main/java/ch/qos/logback/demo/UserServletFilter.java ============================================================================== --- (empty file) +++ logback-demo/trunk/src/main/java/ch/qos/logback/demo/UserServletFilter.java Sun Jun 21 16:56:45 2009 @@ -0,0 +1,63 @@ +package ch.qos.logback.demo; + +import java.io.IOException; +import java.security.Principal; + +import javax.servlet.Filter; +import javax.servlet.FilterChain; +import javax.servlet.FilterConfig; +import javax.servlet.ServletException; +import javax.servlet.ServletRequest; +import javax.servlet.ServletResponse; +import javax.servlet.http.HttpServletRequest; +import javax.servlet.http.HttpSession; + +import org.slf4j.MDC; + +public class UserServletFilter implements Filter { + + boolean userRegistered = false; + + public void destroy() { + } + + public void doFilter(ServletRequest request, ServletResponse response, + + FilterChain chain) throws IOException, ServletException { + + HttpServletRequest req = (HttpServletRequest) request; + Principal principal = req.getUserPrincipal(); + // Please note that we could have also used a cookie to + // retreive the user name + + if (principal != null) { + String username = principal.getName(); + registerUsername(username); + } else { + HttpSession session = req.getSession(); + String username = (String) session + .getAttribute(Constants.USERID_SESSION_KEY); + registerUsername(username); + } + + try { + chain.doFilter(request, response); + } finally { + if (userRegistered) { + MDC.remove(Constants.USERID_MDC_KEY); + } + } + } + + public void init(FilterConfig arg0) throws ServletException { + } + + private void registerUsername(String username) { + System.out.println("in registerUsername username="+username); + if (username != null && username.trim().length() > 0) { + MDC.put(Constants.USERID_MDC_KEY, username); + userRegistered = true; + } + } + +} Modified: logback-demo/trunk/src/main/java/ch/qos/logback/demo/login/LoginAction.java ============================================================================== --- logback-demo/trunk/src/main/java/ch/qos/logback/demo/login/LoginAction.java (original) +++ logback-demo/trunk/src/main/java/ch/qos/logback/demo/login/LoginAction.java Sun Jun 21 16:56:45 2009 @@ -29,7 +29,6 @@ MDC.put(Constants.USERID_MDC_KEY, username); logger.info("Login: " + username + " just logged in."); request.getSession().setAttribute(Constants.USERID_SESSION_KEY, username); - request.setAttribute("a", username); } } Modified: logback-demo/trunk/src/main/java/ch/qos/logback/demo/prime/PrimeAction.java ============================================================================== --- logback-demo/trunk/src/main/java/ch/qos/logback/demo/prime/PrimeAction.java (original) +++ logback-demo/trunk/src/main/java/ch/qos/logback/demo/prime/PrimeAction.java Sun Jun 21 16:56:45 2009 @@ -7,6 +7,7 @@ import org.apache.struts.action.ActionMapping; import org.slf4j.Logger; import org.slf4j.LoggerFactory; +import org.slf4j.MDC; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; @@ -26,6 +27,9 @@ if(number == 99) { logger.info("99 is not a valid value", new Exception("99 is invalid")); } + + System.out.println("*** userid="+MDC.get(Constants.USERID_MDC_KEY)); + NumberCruncher nc = new NumberCruncherImpl(); Long start = System.currentTimeMillis(); Long[] result = nc.factor(number); Modified: logback-demo/trunk/src/main/resources/logback.xml ============================================================================== --- logback-demo/trunk/src/main/resources/logback.xml (original) +++ logback-demo/trunk/src/main/resources/logback.xml Sun Jun 21 16:56:45 2009 @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="UTF-8" ?> - + <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> @@ -35,7 +35,7 @@ </appender> --> -  +  <appender name="CYCLIC" class="ch.qos.logback.core.read.CyclicBufferAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> @@ -53,13 +53,13 @@ -  <turboFilter class="ch.qos.logback.classic.turbo.MDCFilter"> <MDCKey>userid</MDCKey> <Value>sebastien</Value> <OnMatch>ACCEPT</OnMatch> </turboFilter> - --> +  <jmxConfigurator /> - <appender name="SIFT" - class="ch.qos.logback.classic.sift.SiftingAppender"> - <discriminator> - <Key>userid</Key> - <DefaultValue>unknown</DefaultValue> - </discriminator> - <sift> - <appender name="FILE-${userid}" - class="ch.qos.logback.core.FileAppender"> - <File>${userid}.log</File> - <Append>false</Append> - <layout> - <Pattern> - %d [%thread] %-55(%-5level %10mdc %logger{35}) - %msg%n - </Pattern> - </layout> - </appender> - </sift> - </appender> <root level="${lb_level:-ERROR}"> <appender-ref ref="STDOUT" /> - <appender-ref ref="SIFT" /> - <appender-ref ref="CYCLIC" /> + <appender-ref ref="FILE" /> + <appender-ref ref="CYCLIC" /> </root> </configuration> Modified: logback-demo/trunk/src/main/resources/parts/sifting.xml ============================================================================== --- logback-demo/trunk/src/main/resources/parts/sifting.xml (original) +++ logback-demo/trunk/src/main/resources/parts/sifting.xml Sun Jun 21 16:56:45 2009 @@ -17,4 +17,3 @@ </appender> </sift> </appender> - Modified: logback-demo/trunk/src/main/webapp/WEB-INF/web.xml ============================================================================== --- logback-demo/trunk/src/main/webapp/WEB-INF/web.xml (original) +++ logback-demo/trunk/src/main/webapp/WEB-INF/web.xml Sun Jun 21 16:56:45 2009 @@ -5,6 +5,19 @@ <display-name>logback-demo</display-name> + <filter> + <filter-name>mdc_filter</filter-name> + <filter-class> + ch.qos.logback.demo.UserServletFilter + </filter-class> + </filter> + <filter-mapping> + <filter-name>mdc_filter</filter-name> + <url-pattern>/*</url-pattern> + </filter-mapping> + + +  <env-entry> <description>JNDI logging context for this app</description>

1 0

[JIRA] Created: (LBGENERAL-30) logback fails to initialise when loaded from bootstrap classpath
by Henric Larsson (JIRA) 18 Jun '09

18 Jun '09

logback fails to initialise when loaded from bootstrap classpath ---------------------------------------------------------------- Key: LBGENERAL-30 URL: http://jira.qos.ch/browse/LBGENERAL-30 Project: logback-general Issue Type: Bug Affects Versions: 0.9.14, 0.9.15 Reporter: Henric Larsson Assignee: Logback dev list Attachments: classloader.patch When logback is put in the endorsed library path of the jdk, it fails to initialise because the getClassLoader() call returns null in a couple of places. Returning null is expected when the classloader is the bootstrap classloader, as is the case when logback is loaded from the endorsed directory. Here's a snippet from the sun jdk javadoc for Class.getClassLoader() "Returns the class loader for the class. Some implementations may use null to represent the bootstrap class loader. This method will return null in such implementations if this class was loaded by the bootstrap class loader." I'm using jacorb 2.3.1, which uses slf4j-api 1.5.6. Jacorb is required to be in the endorsed lib to work, and hence any logging implementation has to go there too. I patched my logback instance to return the system classloader when the null classloader is encounterd. Attaching patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 3

svn commit: r2297 - in logback/trunk: logback-classic/src/main/java/ch/qos/logback/classic/util logback-core/src/main/java/ch/qos/logback/core/util
by noreply.ceki＠qos.ch 18 Jun '09

18 Jun '09

Author: ceki Date: Thu Jun 18 18:10:04 2009 New Revision: 2297 Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/util/ContextInitializer.java logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/Loader.java logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/OptionHelper.java Log: Fixing LBCORE-100 Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/util/ContextInitializer.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/util/ContextInitializer.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/util/ContextInitializer.java Thu Jun 18 18:10:04 2009 @@ -80,7 +80,7 @@ } public URL findURLOfDefaultConfigurationFile(boolean updateStatus) { - ClassLoader myClassLoader = this.getClass().getClassLoader(); + ClassLoader myClassLoader = Loader.getClassLoaderOfObject(this); URL url = findConfigFileURLFromSystemProperties(myClassLoader, updateStatus); if (url != null) { return url; Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/Loader.java ============================================================================== --- logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/Loader.java (original) +++ logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/Loader.java Thu Jun 18 18:10:04 2009 @@ -83,7 +83,7 @@ * @return */ public static URL getResourceBySelfClassLoader(String resource) { - return getResource(resource, Loader.class.getClassLoader()); + return getResource(resource, getClassLoaderOfClass(Loader.class)); } // private static URL getResourceByTCL(String resource) { @@ -103,11 +103,41 @@ @SuppressWarnings("unchecked") public static Class loadClass(String clazz, Context context) throws ClassNotFoundException { - ClassLoader cl = context.getClass().getClassLoader(); + ClassLoader cl = getClassLoaderOfObject(context); return cl.loadClass(clazz); } /** + * Get the class loader of the object passed as argument. Return the system + * class loader if appropriate. + * + * @param o + * @return + */ + public static ClassLoader getClassLoaderOfObject(Object o) { + if (o == null) { + throw new NullPointerException("Argument cannot be null"); + } + return getClassLoaderOfClass(o.getClass()); + } + + /** + * Return the class loader which loaded the class passed as argument. Return + * the system class loader if appropriate. + * + * @param clazz + * @return + */ + public static ClassLoader getClassLoaderOfClass(Class clazz) { + ClassLoader cl = clazz.getClassLoader(); + if (cl == null) { + return ClassLoader.getSystemClassLoader(); + } else { + return cl; + } + } + + /** * If running under JDK 1.2 load the specified class using the * <code>Thread</code> <code>contextClassLoader</code> if that fails try * Class.forname. Under JDK 1.1 only Class.forName is used. Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/OptionHelper.java ============================================================================== --- logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/OptionHelper.java (original) +++ logback/trunk/logback-core/src/main/java/ch/qos/logback/core/util/OptionHelper.java Thu Jun 18 18:10:04 2009 @@ -9,7 +9,6 @@ */ package ch.qos.logback.core.util; - import java.util.Properties; import ch.qos.logback.core.Context; @@ -22,11 +21,12 @@ public class OptionHelper { public static Object instantiateByClassName(String className, - Class superClass, Context context) throws IncompatibleClassException, DynamicClassLoadingException { - ClassLoader classLoader = context.getClass().getClassLoader(); + Class superClass, Context context) throws IncompatibleClassException, + DynamicClassLoadingException { + ClassLoader classLoader = Loader.getClassLoaderOfObject(context); return instantiateByClassName(className, superClass, classLoader); } - + @SuppressWarnings("unchecked") public static Object instantiateByClassName(String className, Class superClass, ClassLoader classLoader) @@ -74,57 +74,54 @@ final static int DELIM_START_LEN = 2; final static int DELIM_STOP_LEN = 1; final static String _IS_UNDEFINED = "_IS_UNDEFINED"; - + /** * Perform variable substitution in string <code>val</code> from the values * of keys found in context property map, and if that fails, then in the * system properties. * - * - * The variable substitution delimeters are ${ and }. + * The variable substitution delimeters are ${ and }. * - * - * For example, if the context property map contains a property "key1" set as - * "value1", then the call + * For example, if the context property map contains a property "key1" set + * as "value1", then the call * * <pre> * String s = OptionConverter.substituteVars("Value of key is ${key1}.", context);</pre> + * * will set the variable <code>s</code> to "Value of key is value1.". * - * - * If no value could be found for the specified key in the context map, then - * the system properties are searched, if that fails, then substitution defaults - * to appending "_IS_UNDEFINED" to the key name. - * - * - * For example, if not the context not the system properties contains no value for the key - * "inexistentKey", then the call + * If no value could be found for the specified key in the context map, + * then the system properties are searched, if that fails, then substitution + * defaults to appending "_IS_UNDEFINED" to the key name. + * + * For example, if not the context not the system properties contains no + * value for the key "inexistentKey", then the call * * <pre> * String s = OptionConverter.subsVars( * "Value of inexistentKey is [${inexistentKey}]", context);</pre> - * will set <code>s</code> to "Value of inexistentKey is [inexistentKey_IS_UNDEFINED]". * - * - * Nevertheless, it is possible to specify a default substitution value using - * the ":-" operator. For example, the call + * will set <code>s</code> to "Value of inexistentKey is + * [inexistentKey_IS_UNDEFINED]". + * + * Nevertheless, it is possible to specify a default substitution value + * using the ":-" operator. For example, the call * * <pre> * String s = OptionConverter.subsVars("Value of key is [${key2:-val2}]", context);</pre> + * * will set <code>s</code> to "Value of key is [val2]" even if the "key2" * property is not set. * - * - * An {@link java.lang.IllegalArgumentException} is thrown if <code>val</code> - * contains a start delimeter "${" which is not balanced by a stop delimeter - * "}". - * - + * An {@link java.lang.IllegalArgumentException} is thrown if + * <code>val</code> contains a start delimeter "${" which is not balanced by + * a stop delimeter "}". + * * * @param val - * The string on which variable substitution is performed. + * The string on which variable substitution is performed. * @throws IllegalArgumentException - * if <code>val</code> is malformed. + * if <code>val</code> is malformed. */ public static String substVars(String val, PropertyContainer pc) { @@ -191,7 +188,7 @@ sbuf.append(recursiveReplacement); } else { // if we could not find a replacement, then signal the error - sbuf.append(key+"_IS_UNDEFINED"); + sbuf.append(key + "_IS_UNDEFINED"); } i = k + DELIM_STOP_LEN; @@ -205,9 +202,9 @@ * {@link SecurityException} is absorbed. * * @param key - * The key to search for. + * The key to search for. * @param def - * The default value to return. + * The default value to return. * @return the string value of the system property, or the default value if * there is no property with that key. */ @@ -224,8 +221,8 @@ * {@link SecurityException} is absorbed. * * @param key - * The key to search for. - + * The key to search for. + * * @return the string value of the system property. */ public static String getSystemProperty(String key) { @@ -235,6 +232,7 @@ return null; } } + /** * Very similar to {@link System#getProperties()} except that the * {@link SecurityException} is absorbed. @@ -248,7 +246,7 @@ return new Properties(); } } - + static public String[] extractDefaultReplacement(String key) { String[] result = new String[2]; result[0] = key; @@ -265,8 +263,7 @@ * <code>value</code> is "false", then <code>true</code> is returned. * Otherwise, <code>default</code> is returned. * - * - * Case of value is unimportant. + * Case of value is unimportant. */ public static boolean toBoolean(String value, boolean dEfault) { if (value == null) {

1 0

[JIRA] Commented: (LBCLASSIC-36) Synchronization of SimpleDateFormat object in DateConverter
by Ceki Gulcu (JIRA) 17 Jun '09

17 Jun '09

[ http://jira.qos.ch/browse/LBCLASSIC-36?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu commented on LBCLASSIC-36: ------------------------------------- Right. The working assumption here is that the scope of synchronization will be reduced in future logback versions. > Synchronization of SimpleDateFormat object in DateConverter > ----------------------------------------------------------- > > Key: LBCLASSIC-36 > URL: http://jira.qos.ch/browse/LBCLASSIC-36 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Anders Hammar > Assignee: Ceki Gulcu > Attachments: DateConverter_patch.java, DateFormatPerfTest.java, dateformattest.zip, DoubleCheckedLocking.patch > > > According to the API documentation of SimpleDateFormat, date formats are not synchronized and it is recommended to create separate format instances for each thread. > However, a possibly simpler (mer efficient) solution would be to synchronize on the SimpleDateFormat object in the convert() method to prevent two threads to access it concurrently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Commented: (LBCLASSIC-36) Synchronization of SimpleDateFormat object in DateConverter
by Ralph Goers (JIRA) 17 Jun '09

17 Jun '09

[ http://jira.qos.ch/browse/LBCLASSIC-36?page=com.atlassian.jira.plugin.syste… ] Ralph Goers commented on LBCLASSIC-36: -------------------------------------- I am seeing similar improvements. While I recommend adopting these improvements they won't mean much while the whole appender is synchronized. > Synchronization of SimpleDateFormat object in DateConverter > ----------------------------------------------------------- > > Key: LBCLASSIC-36 > URL: http://jira.qos.ch/browse/LBCLASSIC-36 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Anders Hammar > Assignee: Ceki Gulcu > Attachments: DateConverter_patch.java, DateFormatPerfTest.java, dateformattest.zip, DoubleCheckedLocking.patch > > > According to the API documentation of SimpleDateFormat, date formats are not synchronized and it is recommended to create separate format instances for each thread. > However, a possibly simpler (mer efficient) solution would be to synchronize on the SimpleDateFormat object in the convert() method to prevent two threads to access it concurrently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Commented: (LBCLASSIC-36) Synchronization of SimpleDateFormat object in DateConverter
by Joern Huxhorn (JIRA) 17 Jun '09

17 Jun '09

[ http://jira.qos.ch/browse/LBCLASSIC-36?page=com.atlassian.jira.plugin.syste… ] Joern Huxhorn commented on LBCLASSIC-36: ---------------------------------------- More important than the performance increase is the fact that double-checked locking is broken - so it wouldn't have worked as it should have in RL. > Synchronization of SimpleDateFormat object in DateConverter > ----------------------------------------------------------- > > Key: LBCLASSIC-36 > URL: http://jira.qos.ch/browse/LBCLASSIC-36 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Anders Hammar > Assignee: Ceki Gulcu > Attachments: DateConverter_patch.java, DateFormatPerfTest.java, dateformattest.zip, DoubleCheckedLocking.patch > > > According to the API documentation of SimpleDateFormat, date formats are not synchronized and it is recommended to create separate format instances for each thread. > However, a possibly simpler (mer efficient) solution would be to synchronize on the SimpleDateFormat object in the convert() method to prevent two threads to access it concurrently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Commented: (LBCLASSIC-36) Synchronization of SimpleDateFormat object in DateConverter
by Joern Huxhorn (JIRA) 17 Jun '09

17 Jun '09

[ http://jira.qos.ch/browse/LBCLASSIC-36?page=com.atlassian.jira.plugin.syste… ] Joern Huxhorn commented on LBCLASSIC-36: ---------------------------------------- Well, the above test looks like this from within IDEA: Raw - JDK: 4992 ns Joda: 5533 ns - Difference: -10.837339% Synchronized DateFormat: 0.4826 seconds Unsynchronized DateFormat: 1.7025 seconds ThreadLocal DateFormat: 0.1858 seconds Joda DateTimeFormatter: 0.0908 seconds And values are fluctuating quite a bit on reruns, that's why I'm asking... Raw - JDK: 4864 ns Joda: 5348 ns - Difference: -9.950658% Synchronized DateFormat: 0.4799 seconds Unsynchronized DateFormat: 1.5900 seconds ThreadLocal DateFormat: 0.1806 seconds Joda DateTimeFormatter: 0.1252 seconds Raw - JDK: 5030 ns Joda: 5719 ns - Difference: -13.697813% Synchronized DateFormat: 0.4813 seconds Unsynchronized DateFormat: 1.6982 seconds ThreadLocal DateFormat: 0.1870 seconds Joda DateTimeFormatter: 0.0838 seconds ... > Synchronization of SimpleDateFormat object in DateConverter > ----------------------------------------------------------- > > Key: LBCLASSIC-36 > URL: http://jira.qos.ch/browse/LBCLASSIC-36 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Anders Hammar > Assignee: Ceki Gulcu > Attachments: DateConverter_patch.java, DateFormatPerfTest.java, dateformattest.zip, DoubleCheckedLocking.patch > > > According to the API documentation of SimpleDateFormat, date formats are not synchronized and it is recommended to create separate format instances for each thread. > However, a possibly simpler (mer efficient) solution would be to synchronize on the SimpleDateFormat object in the convert() method to prevent two threads to access it concurrently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Commented: (LBCLASSIC-36) Synchronization of SimpleDateFormat object in DateConverter
by Ceki Gulcu (JIRA) 17 Jun '09

17 Jun '09

[ http://jira.qos.ch/browse/LBCLASSIC-36?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu commented on LBCLASSIC-36: ------------------------------------- With your patch applied: === DateFormatting === java.runtime.version = 1.6.0_05-b13 java.vendor = Sun Microsystems Inc. java.version = 1.6.0_05 os.name = Windows XP os.version = 5.1 JODA: total of 21601629 operations, or 7200 operations per millisecond SDF: total of 28017761 operations, or 9339 operations per millisecond Approx. 5 fold improvement. Very nice. I am running the test from within Eclipse. Why do you think IDEA or Eclipse influences the outcome? Do you have anything specific in mind? > Synchronization of SimpleDateFormat object in DateConverter > ----------------------------------------------------------- > > Key: LBCLASSIC-36 > URL: http://jira.qos.ch/browse/LBCLASSIC-36 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Anders Hammar > Assignee: Ceki Gulcu > Attachments: DateConverter_patch.java, DateFormatPerfTest.java, dateformattest.zip, DoubleCheckedLocking.patch > > > According to the API documentation of SimpleDateFormat, date formats are not synchronized and it is recommended to create separate format instances for each thread. > However, a possibly simpler (mer efficient) solution would be to synchronize on the SimpleDateFormat object in the convert() method to prevent two threads to access it concurrently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Updated: (LBCLASSIC-36) Synchronization of SimpleDateFormat object in DateConverter
by Joern Huxhorn (JIRA) 17 Jun '09

17 Jun '09

[ http://jira.qos.ch/browse/LBCLASSIC-36?page=com.atlassian.jira.plugin.syste… ] Joern Huxhorn updated LBCLASSIC-36: ----------------------------------- Attachment: DoubleCheckedLocking.patch === DateFormatting === java.runtime.version = 1.6.0_13-b03-211 java.vendor = Apple Inc. java.version = 1.6.0_13 os.name = Mac OS X os.version = 10.5.7 JODA: total of 52011401 operations, or 17337 operations per millisecond SDF: total of 52664135 operations, or 17554 operations per millisecond I've removed the double-checked locking from the example app. http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html How are you executing this app? I started it from within IDEA but I fear that this influences the outcome... > Synchronization of SimpleDateFormat object in DateConverter > ----------------------------------------------------------- > > Key: LBCLASSIC-36 > URL: http://jira.qos.ch/browse/LBCLASSIC-36 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Anders Hammar > Assignee: Ceki Gulcu > Attachments: DateConverter_patch.java, DateFormatPerfTest.java, dateformattest.zip, DoubleCheckedLocking.patch > > > According to the API documentation of SimpleDateFormat, date formats are not synchronized and it is recommended to create separate format instances for each thread. > However, a possibly simpler (mer efficient) solution would be to synchronize on the SimpleDateFormat object in the convert() method to prevent two threads to access it concurrently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Commented: (LBCLASSIC-36) Synchronization of SimpleDateFormat object in DateConverter
by Joern Huxhorn (JIRA) 17 Jun '09

17 Jun '09

[ http://jira.qos.ch/browse/LBCLASSIC-36?page=com.atlassian.jira.plugin.syste… ] Joern Huxhorn commented on LBCLASSIC-36: ---------------------------------------- This was just a side-effect of trying to get logback to compile using "mvn clean install". I'll take another look at DateFormatPerftest. My suggestion above is still standing (I know, we just had a comment race-condition ;)): how about the interface? > Synchronization of SimpleDateFormat object in DateConverter > ----------------------------------------------------------- > > Key: LBCLASSIC-36 > URL: http://jira.qos.ch/browse/LBCLASSIC-36 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Anders Hammar > Assignee: Ceki Gulcu > Attachments: DateConverter_patch.java, DateFormatPerfTest.java, dateformattest.zip > > > According to the API documentation of SimpleDateFormat, date formats are not synchronized and it is recommended to create separate format instances for each thread. > However, a possibly simpler (mer efficient) solution would be to synchronize on the SimpleDateFormat object in the convert() method to prevent two threads to access it concurrently. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0