You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Myrna van Lunteren (JIRA)" <de...@db.apache.org> on 2006/04/14 09:26:00 UTC
[jira] Created: (DERBY-1221) runtimestatistics time shows large
number instead of 0 with ibm15 on zOS
runtimestatistics time shows large number instead of 0 with ibm15 on zOS
------------------------------------------------------------------------
Key: DERBY-1221
URL: http://issues.apache.org/jira/browse/DERBY-1221
Project: Derby
Type: Bug
Versions: 10.0.2.0
Environment: zOS with ibm15
Reporter: Myrna van Lunteren
A number of tests that printout runtimestatistics fail on zOS with ibm15, because instead of a 'time' of 0, the time is some large number.
Tests that fail like this:
derbylang/derbylang.fail:lang/aggregateOptimization.sql
derbylang/derbylang.fail:lang/distinctElimination.sql
derbylang/derbylang.fail:lang/predicatePushdown.sql
derbylang/derbylang.fail:lang/predicatesIntoViews.sql
derbylang/derbylang.fail:lang/staleplans.sql
derbylang/derbylang.fail:lang/wisconsin.java
encryptionAll/encryption/storemats.fail:store/access.sql (in various encryption schemes)
This is the kind of diff I see:
---------------------
*** Start: access jdk1.5.0 storemats:storemats 2006-04-13 09:46:01 ***
2912 del
< Execute Time = 0
2912a2912
> Execute Time = -3638779204078642344
2921 del
< next time (milliseconds) = 0
2921a2921
> next time (milliseconds) = 3638779204078642344
2934 del
< next time (milliseconds) = 0
2934a2934
> next time (milliseconds) = 3668750241784351640
2991 del
< Execute Time = 0
2991a2991
> Execute Time = -4015137258338621104
3000 del
< next time (milliseconds) = 0
3000a3000
> next time (milliseconds) = 4015137258338621104
....
------------------------------
As this problem occurs only with ibm15 and not with ibm14, I think somewhere in the runtime statistics printing code we may be using BigDecimal somehow, and it's not done in an encoding-safe way. But that is just a guess.
I'm leaving this one as Major, because it's easy to miss things when looking through test failures this way, but I can also understand that this would be considered minor, as apparently the paths taken by the optimizer are actually correct and it's only the printing out that has the large numbers. Yet again on the other hand I imagine it makes runtimestatistics less useful, with these disconcertingly large number of milliseconds.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1221) runtimestatistics time shows large
number instead of 0 with ibm15 on zOS
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren closed DERBY-1221.
-------------------------------------
Resolution: Invalid
This was indeed a JVM issue and was fixed with the next version of the JVM.
> runtimestatistics time shows large number instead of 0 with ibm15 on zOS
> ------------------------------------------------------------------------
>
> Key: DERBY-1221
> URL: https://issues.apache.org/jira/browse/DERBY-1221
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.1.3.1
> Environment: zOS with ibm15
> Reporter: Myrna van Lunteren
>
> A number of tests that printout runtimestatistics fail on zOS with ibm15, because instead of a 'time' of 0, the time is some large number.
> Tests that fail like this:
> derbylang/derbylang.fail:lang/aggregateOptimization.sql
> derbylang/derbylang.fail:lang/distinctElimination.sql
> derbylang/derbylang.fail:lang/predicatePushdown.sql
> derbylang/derbylang.fail:lang/predicatesIntoViews.sql
> derbylang/derbylang.fail:lang/staleplans.sql
> derbylang/derbylang.fail:lang/wisconsin.java
> encryptionAll/encryption/storemats.fail:store/access.sql (in various encryption schemes)
> This is the kind of diff I see:
> ---------------------
> *** Start: access jdk1.5.0 storemats:storemats 2006-04-13 09:46:01 ***
> 2912 del
> < Execute Time = 0
> 2912a2912
> > Execute Time = -3638779204078642344
> 2921 del
> < next time (milliseconds) = 0
> 2921a2921
> > next time (milliseconds) = 3638779204078642344
> 2934 del
> < next time (milliseconds) = 0
> 2934a2934
> > next time (milliseconds) = 3668750241784351640
> 2991 del
> < Execute Time = 0
> 2991a2991
> > Execute Time = -4015137258338621104
> 3000 del
> < next time (milliseconds) = 0
> 3000a3000
> > next time (milliseconds) = 4015137258338621104
> ....
> ------------------------------
> As this problem occurs only with ibm15 and not with ibm14, I think somewhere in the runtime statistics printing code we may be using BigDecimal somehow, and it's not done in an encoding-safe way. But that is just a guess.
> I'm leaving this one as Major, because it's easy to miss things when looking through test failures this way, but I can also understand that this would be considered minor, as apparently the paths taken by the optimizer are actually correct and it's only the printing out that has the large numbers. Yet again on the other hand I imagine it makes runtimestatistics less useful, with these disconcertingly large number of milliseconds.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1221) runtimestatistics time shows large
number instead of 0 with ibm15 on zOS
Posted by "Myrna van Lunteren (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1221?page=all ]
Myrna van Lunteren updated DERBY-1221:
--------------------------------------
Version: 10.1.2.3
(was: 10.0.2.0)
I confirmed that this problem also exists with current 10.1.2.4 builds, but *not* with ibm142.
> runtimestatistics time shows large number instead of 0 with ibm15 on zOS
> ------------------------------------------------------------------------
>
> Key: DERBY-1221
> URL: http://issues.apache.org/jira/browse/DERBY-1221
> Project: Derby
> Type: Bug
> Versions: 10.1.2.3
> Environment: zOS with ibm15
> Reporter: Myrna van Lunteren
>
> A number of tests that printout runtimestatistics fail on zOS with ibm15, because instead of a 'time' of 0, the time is some large number.
> Tests that fail like this:
> derbylang/derbylang.fail:lang/aggregateOptimization.sql
> derbylang/derbylang.fail:lang/distinctElimination.sql
> derbylang/derbylang.fail:lang/predicatePushdown.sql
> derbylang/derbylang.fail:lang/predicatesIntoViews.sql
> derbylang/derbylang.fail:lang/staleplans.sql
> derbylang/derbylang.fail:lang/wisconsin.java
> encryptionAll/encryption/storemats.fail:store/access.sql (in various encryption schemes)
> This is the kind of diff I see:
> ---------------------
> *** Start: access jdk1.5.0 storemats:storemats 2006-04-13 09:46:01 ***
> 2912 del
> < Execute Time = 0
> 2912a2912
> > Execute Time = -3638779204078642344
> 2921 del
> < next time (milliseconds) = 0
> 2921a2921
> > next time (milliseconds) = 3638779204078642344
> 2934 del
> < next time (milliseconds) = 0
> 2934a2934
> > next time (milliseconds) = 3668750241784351640
> 2991 del
> < Execute Time = 0
> 2991a2991
> > Execute Time = -4015137258338621104
> 3000 del
> < next time (milliseconds) = 0
> 3000a3000
> > next time (milliseconds) = 4015137258338621104
> ....
> ------------------------------
> As this problem occurs only with ibm15 and not with ibm14, I think somewhere in the runtime statistics printing code we may be using BigDecimal somehow, and it's not done in an encoding-safe way. But that is just a guess.
> I'm leaving this one as Major, because it's easy to miss things when looking through test failures this way, but I can also understand that this would be considered minor, as apparently the paths taken by the optimizer are actually correct and it's only the printing out that has the large numbers. Yet again on the other hand I imagine it makes runtimestatistics less useful, with these disconcertingly large number of milliseconds.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1221) runtimestatistics time shows large
number instead of 0 with ibm15 on zOS
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1221?page=all ]
Kathey Marsden updated DERBY-1221:
----------------------------------
Component: SQL
> runtimestatistics time shows large number instead of 0 with ibm15 on zOS
> ------------------------------------------------------------------------
>
> Key: DERBY-1221
> URL: http://issues.apache.org/jira/browse/DERBY-1221
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.1.2.3
> Environment: zOS with ibm15
> Reporter: Myrna van Lunteren
>
> A number of tests that printout runtimestatistics fail on zOS with ibm15, because instead of a 'time' of 0, the time is some large number.
> Tests that fail like this:
> derbylang/derbylang.fail:lang/aggregateOptimization.sql
> derbylang/derbylang.fail:lang/distinctElimination.sql
> derbylang/derbylang.fail:lang/predicatePushdown.sql
> derbylang/derbylang.fail:lang/predicatesIntoViews.sql
> derbylang/derbylang.fail:lang/staleplans.sql
> derbylang/derbylang.fail:lang/wisconsin.java
> encryptionAll/encryption/storemats.fail:store/access.sql (in various encryption schemes)
> This is the kind of diff I see:
> ---------------------
> *** Start: access jdk1.5.0 storemats:storemats 2006-04-13 09:46:01 ***
> 2912 del
> < Execute Time = 0
> 2912a2912
> > Execute Time = -3638779204078642344
> 2921 del
> < next time (milliseconds) = 0
> 2921a2921
> > next time (milliseconds) = 3638779204078642344
> 2934 del
> < next time (milliseconds) = 0
> 2934a2934
> > next time (milliseconds) = 3668750241784351640
> 2991 del
> < Execute Time = 0
> 2991a2991
> > Execute Time = -4015137258338621104
> 3000 del
> < next time (milliseconds) = 0
> 3000a3000
> > next time (milliseconds) = 4015137258338621104
> ....
> ------------------------------
> As this problem occurs only with ibm15 and not with ibm14, I think somewhere in the runtime statistics printing code we may be using BigDecimal somehow, and it's not done in an encoding-safe way. But that is just a guess.
> I'm leaving this one as Major, because it's easy to miss things when looking through test failures this way, but I can also understand that this would be considered minor, as apparently the paths taken by the optimizer are actually correct and it's only the printing out that has the large numbers. Yet again on the other hand I imagine it makes runtimestatistics less useful, with these disconcertingly large number of milliseconds.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1221) runtimestatistics time shows large
number instead of 0 with ibm15 on zOS
Posted by "Manjula Kutty (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1221?page=comments#action_12414143 ]
Manjula Kutty commented on DERBY-1221:
--------------------------------------
I ran into this problem even on a windows platform with the most recent ibm15 build. So it is not a ZOS specific problem, rather it is a jvm issue. Will be contacting the jvm people for this issue
> runtimestatistics time shows large number instead of 0 with ibm15 on zOS
> ------------------------------------------------------------------------
>
> Key: DERBY-1221
> URL: http://issues.apache.org/jira/browse/DERBY-1221
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.1.2.3
> Environment: zOS with ibm15
> Reporter: Myrna van Lunteren
>
> A number of tests that printout runtimestatistics fail on zOS with ibm15, because instead of a 'time' of 0, the time is some large number.
> Tests that fail like this:
> derbylang/derbylang.fail:lang/aggregateOptimization.sql
> derbylang/derbylang.fail:lang/distinctElimination.sql
> derbylang/derbylang.fail:lang/predicatePushdown.sql
> derbylang/derbylang.fail:lang/predicatesIntoViews.sql
> derbylang/derbylang.fail:lang/staleplans.sql
> derbylang/derbylang.fail:lang/wisconsin.java
> encryptionAll/encryption/storemats.fail:store/access.sql (in various encryption schemes)
> This is the kind of diff I see:
> ---------------------
> *** Start: access jdk1.5.0 storemats:storemats 2006-04-13 09:46:01 ***
> 2912 del
> < Execute Time = 0
> 2912a2912
> > Execute Time = -3638779204078642344
> 2921 del
> < next time (milliseconds) = 0
> 2921a2921
> > next time (milliseconds) = 3638779204078642344
> 2934 del
> < next time (milliseconds) = 0
> 2934a2934
> > next time (milliseconds) = 3668750241784351640
> 2991 del
> < Execute Time = 0
> 2991a2991
> > Execute Time = -4015137258338621104
> 3000 del
> < next time (milliseconds) = 0
> 3000a3000
> > next time (milliseconds) = 4015137258338621104
> ....
> ------------------------------
> As this problem occurs only with ibm15 and not with ibm14, I think somewhere in the runtime statistics printing code we may be using BigDecimal somehow, and it's not done in an encoding-safe way. But that is just a guess.
> I'm leaving this one as Major, because it's easy to miss things when looking through test failures this way, but I can also understand that this would be considered minor, as apparently the paths taken by the optimizer are actually correct and it's only the printing out that has the large numbers. Yet again on the other hand I imagine it makes runtimestatistics less useful, with these disconcertingly large number of milliseconds.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira