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