All,

I just wanted to sound off about this as I know I borrowed this snippet of code 
from someone on this mailing list a long time ago, and I think there may be a 
few others out there still using it.  Subclassing the type converter factory to 
cache the instances instead of reinstating every time like so:

public class TypeConverterFactory extends DefaultTypeConverterFactory  {

      private static Map<Class<? extends TypeConverter<?>>, TypeConverter<?>> 
converterInstanceMap =
            new ConcurrentHashMap<Class<? extends TypeConverter<?>>, 
TypeConverter<?>>();


      @SuppressWarnings("unchecked")      // super method uses raw type .. 
should be <?>
      @Override
      public TypeConverter getInstance(Class<? extends TypeConverter> clazz,
                  Locale locale) throws Exception {
            TypeConverter<?> typeConverter = converterInstanceMap.get(clazz);
            return typeConverter == null ? super.getInstance(clazz, locale) : 
typeConverter;
      }
}

.. is a bad idea, as it saves instances of the DateTypeConverter and 
NumberTypeConverter which are NOT thread safe.  I've had to remove this to get 
my load tests to pass.

At first I thought it was a bug that those are not thread safe, then I noticed 
this instance cache.   I'd like to propose that the default converter works 
this way to avoid this inefficient instantiation on every request, and that the 
DateTypeConverter and NumberTypeConverter  either synchronize on the 
SimpleDateFormat and NumberFormat instances or pool them.  The sync approach 
would be a pretty easy patch, I'd be happy to submit it, pooling would be 
better but would be more complex and probably add a dependency.  Any thoughts 
on that?

Thanks,
John
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Reply via email to