search

unlockha / beanio

Automatically exported from code.google.com/p/beanio
Apache License 2.0
1 stars 0 forks source link

DateTypeHandlerSupport not thread-safe #131

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Create multiple Unmarshallers (one per thread) from the same StreamFactory
2. Unmarshall records with a date in each of the threads

What is the expected output? What do you see instead?
All records get unmarshalled correctely. Instead, Exceptions get thrown.

What version of BeanIO are you using? What JDK version?
BeanIO 2.1.0

Please provide any additional information below.
While the documentation claims that "All included BeanIO type handlers are 
thread safe", DateTypeHandlerSupport potentially uses the same SimpleDateFormat 
for multiple Unmarshaller instances. Since SimpleDateFormat is not thread-safe 
this causes the behaviour as shown. Switching to a custom TypeHandler that uses 
a thread-local SimpleDateFormat solves the problem.

Original issue reported on code.google.com by gyr...@gmail.com on 24 Mar 2015 at 12:58

GoogleCodeExporter commented 8 years ago 
Same behaviour when using beanIO in a camel route.

Strange exceptions that trace back to SimpleDateFormat not being thread safe.

Original comment by pluim...@gmail.com on 27 Apr 2015 at 12:38

pjklauser commented 8 years ago

I can reproduce this problem, it is serious - it basically makes the built in type handler for date formatting not usable ( since multiple bean writers are going to be used by multiple threads )

24.05.2016 16:06:19,991 | WARN | WorkCalculation] | RuntimeErrorHandler | 361 - phx-work-integration - 4.2.0.SNAPSHOT | Unmanaged runtimeException 43 java.lang.ArrayIndexOutOfBoundsException: 43 at sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(Unknown Source)[:1.8.0_74] at java.util.GregorianCalendar.computeFields(Unknown Source)[:1.8.0_74] at java.util.GregorianCalendar.computeFields(Unknown Source)[:1.8.0_74] at java.util.Calendar.setTimeInMillis(Unknown Source)[:1.8.0_74] at java.util.Calendar.setTime(Unknown Source)[:1.8.0_74] at java.text.SimpleDateFormat.format(Unknown Source)[:1.8.0_74] at java.text.SimpleDateFormat.format(Unknown Source)[:1.8.0_74] at java.text.DateFormat.format(Unknown Source)[:1.8.0_74] at org.beanio.types.DateTypeHandlerSupport.formatDate(DateTypeHandlerSupport.java:80)[310:org.beanio:2.1.0] at org.beanio.types.DateTypeHandler.format(DateTypeHandler.java:60)[310:org.beanio:2.1.0] at org.beanio.internal.parser.Field.formatValue(Field.java:354) at org.beanio.internal.parser.Field.marshal(Field.java:194) at org.beanio.internal.parser.Segment.marshal(Segment.java:147) at org.beanio.internal.parser.Record.marshal(Record.java:52) at org.beanio.internal.parser.Group.marshal(Group.java:63) at org.beanio.internal.parser.BeanWriterImpl.write(BeanWriterImpl.java:88)

mat6868 commented 2 years ago

I had the same issue using beanIO in a camel route. Dealing with a thousands of files processed with two threads in camel accessing the same beanio, I get sometimes random values, and only with date fields. Replaying the test I get other random values. If I call this beanio sequentially it solves the problem. So I guess the problem that indicated pjklauser is real and serious.