-
-
Notifications
You must be signed in to change notification settings - Fork 190
Open
Labels
bugissue confirmed as bugissue confirmed as bug
Description
Initially, I believed that the following query appears to run forever, I also noticed that it pegs the CPU core running that thread at ~100% utilisation:
fn:current-date() + xs:dayTimeDuration("P1712073600000D")
In comparison:
- BaseX - returns an answer almost instantly.
- Saxon - returns an error instantly:
E value is too large to be expressed in microseconds
.
The root of the problem is not within eXist-db itself. eXist-db is simply relying on a 3rd-party implementation of the Java interface javax.xml.datatype.XMLGregorianCalendar
. Various implementations are available, but eXist-db is using Xerces 2.12 for this.
As the JRE embeds a version of Xerces, we can actually just reproduce the problem in pure Java:
import javax.xml.datatype.DatatypeConfigurationException;
import javax.xml.datatype.DatatypeFactory;
import javax.xml.datatype.Duration;
import javax.xml.datatype.XMLGregorianCalendar;
import java.util.GregorianCalendar;
public class Main {
public static void main(final String args[]) throws DatatypeConfigurationException {
final DatatypeFactory factory = DatatypeFactory.newInstance();
System.out.println("Using implementation from: " + factory.getClass().getPackageName());
// get an XML calendar for `now`
final GregorianCalendar nowCalendar = new GregorianCalendar();
final XMLGregorianCalendar xmlCalendar = factory.newXMLGregorianCalendar(nowCalendar);
// create a very large duration
final Duration duration = factory.newDuration("P1712073600000D");
// add the duration to the XML calendar
xmlCalendar.add(duration);
// print the new date from the XML calendar... do we ever get to this point?
System.out.print(xmlCalendar);
}
}
Tested on:
- Java 8 (1.8.0_382)
- Intel Xeon E5-1650 v3 @ 3.50GHz
Test command:
$ javac Main.java
$ java -cp . Main
Using implementation from: com.sun.org.apache.xerces.internal.jaxp.datatype
4687500329-08-10T18:24:56.192Z
6317.29s user 20.19s system 100% cpu 1:45:34.02 total
The above computation takes in excess of 1 Hour and 45 Minutes!
I believe that there must be room for optimising this, as BaseX is able to provide the result almost instantly...
dizzzz
Metadata
Metadata
Assignees
Labels
bugissue confirmed as bugissue confirmed as bug