3

Edit: It's probably significant that the class name is unusual at the top of the stack trace. I've updated the stack trace to provide a more obvious example of a strange class name we've seen, to emphasise this point. Usually the fully-qualified class name should come before the .<init>.

We are seeing the following error in our Spring Boot microservice when processing certain inbound requests. It is intermittent - only happens on the occasional restart and has only occurred so far on Solaris boxes in our data centre (can't reproduce on a development machine).

This started to occur after adding some new functionality; however we don't believe this new functionality includes anything we think could cause these issues with Gregorian etc. Particularly as these are JDK core classes.

We are using Spring Boot 1.5.4.RELEASE and Java 1.8.0_31 on Solaris 10. 

java.lang.IllegalAccessError: tried to access method p>G^L.<init>(Ljava/util/TimeZone;)V from class sun.util.calendar.Gregorian
    at sun.util.calendar.Gregorian.newCalendarDate(Gregorian.java:85)
    at java.util.GregorianCalendar.<init>(GregorianCalendar.java:738)
    at java.util.Calendar$Builder.build(Calendar.java:1482)
    at sun.util.locale.provider.CalendarProviderImpl.getInstance(CalendarProviderImpl.java:88)
    at java.util.Calendar.createCalendar(Calendar.java:1666)
    at java.util.Calendar.getInstance(Calendar.java:1655)
    at java.text.SimpleDateFormat.initializeCalendar(SimpleDateFormat.java:657)
    at java.text.SimpleDateFormat.<init>(SimpleDateFormat.java:601)
    at org.apache.catalina.valves.AbstractAccessLogValve$DateFormatCache$Cache.<init>(AbstractAccessLogValve.java:251)
    at org.apache.catalina.valves.AbstractAccessLogValve$DateFormatCache$Cache.<init>(AbstractAccessLogValve.java:237)
    at org.apache.catalina.valves.AbstractAccessLogValve$DateFormatCache$Cache.<init>(AbstractAccessLogValve.java:233)
    at org.apache.catalina.valves.AbstractAccessLogValve$DateFormatCache$Cache.<init>(AbstractAccessLogValve.java:207)
    at org.apache.catalina.valves.AbstractAccessLogValve$DateFormatCache.<init>(AbstractAccessLogValve.java:347)
    at org.apache.catalina.valves.AbstractAccessLogValve$1.initialValue(AbstractAccessLogValve.java:392)
    at org.apache.catalina.valves.AbstractAccessLogValve$1.initialValue(AbstractAccessLogValve.java:389)
    at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:180)
    at java.lang.ThreadLocal.get(ThreadLocal.java:170)
    at org.apache.catalina.valves.AbstractAccessLogValve$DateAndTimeElement.addElement(AbstractAccessLogValve.java:1015)
    at org.apache.catalina.valves.AbstractAccessLogValve.log(AbstractAccessLogValve.java:653)
    at org.apache.catalina.core.AccessLogAdapter.log(AccessLogAdapter.java:48)
    at org.apache.catalina.core.ContainerBase.logAccess(ContainerBase.java:1065)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:401)
    at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799)
    at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
    at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:861)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
    at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:745)
Ben Rowland
  • 361
  • 1
  • 5
  • Can you share your pom.xml war packaging and how you deploy the war files? If it's not exposing too much company information. – Zpetkov Feb 12 '18 at 12:05
  • We use Gradle to build a Spring Boot fat jar which contains embedded Tomcat. We then run this application using `java -jar` (rather than deploying a war to an already-running Tomcat container). – Ben Rowland Feb 12 '18 at 12:22
  • @BenRowland so you cannot reproduce the problem, right? Seems to me like TZ problem, are you setting some? Is error related to first request or very first one only after deployment or... ? I'd try to define TZ manually at first - https://stackoverflow.com/a/2493805/384674 Can you also check TZ settings on the box. Is it related to a subset, let say 3 out of 10 servers only? – Betlista Feb 12 '18 at 12:31
  • Re. the TimeZone - we're not setting this directly so I believe it will come from the locale on the box it's deployed on. It's reported by our application as "GB" so I think this is set correctly. The error is intermittent: it either occurs with all requests, or none at all. That is, sometimes a box will suffer the error for all requests, and sometimes it will not. It's not related to any particular box. – Ben Rowland Feb 12 '18 at 12:46
  • Can you check, the same (timezone GB) is set for the box that is broken? – Betlista Feb 12 '18 at 12:54
  • Unfortunately we have only seen the issue on live boxes, and we've rolled back each time. If it happens again I will check this - thanks. – Ben Rowland Feb 12 '18 at 14:32
  • We've now confirmed the user.timezone is "GB" when the problem occurs (as reported by the Spring Boot /env endpoint). – Ben Rowland Feb 13 '18 at 14:07

0 Answers0