Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Threading issue using static Calendar with JDBC ResultSet.getTimestamp #2747

Closed
punktilious opened this issue Sep 8, 2021 · 3 comments
Closed
Assignees
Labels
bug Something isn't working P1 Priority 1 - Must Have persistence

Comments

@punktilious
Copy link
Collaborator

Describe the bug
Calendar is not thread-safe, so the following DAO call can lead to issues because UTC_CALENDAR is declared as static (and therefore shared by multiple threads):

    private static final Calendar UTC_CALENDAR = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
...
    ps.setTimestamp(a++, Timestamp.from(this.fromLastUpdated), UTC_CALENDAR);

Similarly:

    Instant lastUpdated = rs.getTimestamp(2, UTC_CALENDAR).toInstant();

For Derby, we have seen the following error:

java.lang.ArrayIndexOutOfBoundsException: Array index out of range: -602
at java.base/sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(BaseCalendar.java:453)
at java.base/java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2394)
at java.base/java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2815)
at java.base/java.util.Calendar.updateTime(Calendar.java:3428)
at java.base/java.util.Calendar.getTimeInMillis(Calendar.java:1812)
at org.apache.derby.iapi.types.SQLTimestamp.getTimestamp(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedResultSet.getTimestamp(Unknown Source)
at com.ibm.ws.rsadapter.jdbc.WSJdbcResultSet.getTimestamp(WSJdbcResultSet.java:1914)

Environment
4.9.0.

To Reproduce
Steps to reproduce the behavior:

  1. Perform persistence operations with a lot of threads.

Expected behavior
No exceptions and correct date-time

Additional context
We have seen this rarely and only with Derby during testing. But the safe use of the Calendar object depends on how the underlying driver works, so it needs to be fixed for everything. Lesson: don't trust an API to not mutate an object you pass in. Make it immutable.

@punktilious punktilious added the bug Something isn't working label Sep 8, 2021
@punktilious punktilious self-assigned this Sep 8, 2021
@punktilious punktilious added this to the Sprint 2021-12 milestone Sep 8, 2021
@punktilious punktilious added P1 Priority 1 - Must Have persistence labels Sep 8, 2021
@lmsurpre lmsurpre closed this as completed Sep 9, 2021
@lmsurpre
Copy link
Member

lmsurpre commented Sep 9, 2021

We ran some regression testing including a large reindex and havn't seen any issues.

@zachyf
Copy link

zachyf commented Jun 25, 2022

I can confirm I'm seeing the same issue.

@lmsurpre
Copy link
Member

hi @zachyf this issue was marked as resolved in September of 2021. I suggest opening a new issue or providing more information about exactly what you're seeing... e.g. which version of FHIR Server

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working P1 Priority 1 - Must Have persistence
Projects
None yet
Development

No branches or pull requests

3 participants