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 2005/10/13 20:17:05 UTC
[jira] Created: (DERBY-625) hang in unit/cacheService.unit with wctme5.7
hang in unit/cacheService.unit with wctme5.7
---------------------------------------------
Key: DERBY-625
URL: http://issues.apache.org/jira/browse/DERBY-625
Project: Derby
Type: Bug
Versions: 10.1.1.0, 10.2.0.0
Environment: windows with wctme5.7 (j9 version 2.2)
Reporter: Myrna van Lunteren
Test unit/cacheService.unit hangs with wctme5.7 jvm since June...
Can someone familiar with services please have a look?
The hang was not noticed in a timely fashion because our scripts only run with wctme5.7 once a week,
and for 3 months, our nightly tests took too long to complete - and no one paid attention (me included).
I've done some historical research on this, but am no closer to deciding if this is a jvm bug exposed by changed derby functionality or a 'new' derby bug exposed by the wctme5.7 (j9 version 2.2) jvm.
Efforts are hampered by
- absence of commit archive details between June 13 and July 1
- svn cannot backtrack to revisions that happened during incubator time
This is what I found so far:
- in main
- the test ran fine on 6/18/2005, but failed on 6/25/2005.
- From saved commits emails, it appears relevant revisions are between 191353 (jean)
and 201792 (kathey), jean's are all dita related, 2 of kathey's are functionTests only changes.
This leaves the following 2
201792 - kmarsden - DERBY-389,
incubator/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
191755 - kmarsden - DERBY-8 and DERBY-366; mostly test/master updates, but additionally changed:
incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection.java
incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection30.java
- I backtracked the changes from these revisions but still the hang persists...
- 10.1
- I tested build 224373 and 208786 and the could reproduce the hang; but
with build 190628 (which happened to be stting around on my machine) there was no hang.
Thus, with 10.1 branch, the problem was introduced/backported between revision
190628 and revision 208786.
- Looking at a combination of the commit archive for July and my saved commit emails, again, most of these are innocent test or dita updates.
- The following are more interesting:
- 201659 - satheesh - DERBY-388 -
incubator/derby/code/branches/10.0/java/engine/org/apache/derby/impl/sql/GenericPreparedStatement.java
- 208697 - dan - cleanup of published javadoc for embedded jdbc objects
incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedConnectionPoolDataSource.java
incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDataSource.java
incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDriver.java
incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedSimpleDataSource.java
incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedXADataSource.java
- 208776 - andrew - monster commit backport fixes for DERBY-8, DERBY-247, DERBY-276,
DERBY-348, DERBY-354,DERBY-361, DERBY-366, DERBY-389, DERBY-405, DERBY-416, and DERBY-420
- I tried to backtrack my 10.1 branch to revision 208775, but that resulted in:
svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
svn:
Cannot replace a directory from within
In short, historical research has gotten me nowhere.
I looked at the stack of the threads when the program is hanging but it tells me nothing either.
I will attached the stack threads obtained by running the following command:
j9 -jcl:max -Xbootclasspath/p:c:/ive22/lib/database_enabler.jar;c:ive22/lib/classes.zip org.apache.derbyTesting.unitTests.harness.UnitTestMain
on windows and subsequently pressing ctrl-break, and derby.log
Note: this problem does not occur with wsdd5.6 (j9 version 2.1). The test never runs/ran with j9foundation (also wctme5.7).
--
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-625) hang in unit/cacheService.unit with wctme5.7
Posted by "Myrna van Lunteren (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-625?page=all ]
Myrna van Lunteren updated DERBY-625:
-------------------------------------
Priority: Minor (was: Major)
> hang in unit/cacheService.unit with wctme5.7
> --------------------------------------------
>
> Key: DERBY-625
> URL: http://issues.apache.org/jira/browse/DERBY-625
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0, 10.2.0.0
> Environment: windows with wctme5.7 (j9 version 2.2)
> Reporter: Myrna van Lunteren
> Priority: Minor
> Attachments: j9_22_hang.breakout
>
> Test unit/cacheService.unit hangs with wctme5.7 jvm since June...
> Can someone familiar with services please have a look?
> The hang was not noticed in a timely fashion because our scripts only run with wctme5.7 once a week,
> and for 3 months, our nightly tests took too long to complete - and no one paid attention (me included).
> I've done some historical research on this, but am no closer to deciding if this is a jvm bug exposed by changed derby functionality or a 'new' derby bug exposed by the wctme5.7 (j9 version 2.2) jvm.
> Efforts are hampered by
> - absence of commit archive details between June 13 and July 1
> - svn cannot backtrack to revisions that happened during incubator time
> This is what I found so far:
> - in main
> - the test ran fine on 6/18/2005, but failed on 6/25/2005.
> - From saved commits emails, it appears relevant revisions are between 191353 (jean)
> and 201792 (kathey), jean's are all dita related, 2 of kathey's are functionTests only changes.
> This leaves the following 2
> 201792 - kmarsden - DERBY-389,
> incubator/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
> 191755 - kmarsden - DERBY-8 and DERBY-366; mostly test/master updates, but additionally changed:
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection.java
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection30.java
> - I backtracked the changes from these revisions but still the hang persists...
>
>
> - 10.1
> - I tested build 224373 and 208786 and the could reproduce the hang; but
> with build 190628 (which happened to be stting around on my machine) there was no hang.
> Thus, with 10.1 branch, the problem was introduced/backported between revision
> 190628 and revision 208786.
> - Looking at a combination of the commit archive for July and my saved commit emails, again, most of these are innocent test or dita updates.
> - The following are more interesting:
> - 201659 - satheesh - DERBY-388 -
> incubator/derby/code/branches/10.0/java/engine/org/apache/derby/impl/sql/GenericPreparedStatement.java
> - 208697 - dan - cleanup of published javadoc for embedded jdbc objects
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedConnectionPoolDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDriver.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedSimpleDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedXADataSource.java
> - 208776 - andrew - monster commit backport fixes for DERBY-8, DERBY-247, DERBY-276,
> DERBY-348, DERBY-354,DERBY-361, DERBY-366, DERBY-389, DERBY-405, DERBY-416, and DERBY-420
> - I tried to backtrack my 10.1 branch to revision 208775, but that resulted in:
> svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
> svn:
> Cannot replace a directory from within
> In short, historical research has gotten me nowhere.
> I looked at the stack of the threads when the program is hanging but it tells me nothing either.
> I will attached the stack threads obtained by running the following command:
> j9 -jcl:max -Xbootclasspath/p:c:/ive22/lib/database_enabler.jar;c:ive22/lib/classes.zip org.apache.derbyTesting.unitTests.harness.UnitTestMain
> on windows and subsequently pressing ctrl-break, and derby.log
> Note: this problem does not occur with wsdd5.6 (j9 version 2.1). The test never runs/ran with j9foundation (also wctme5.7).
--
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] Reopened: (DERBY-625) hang in unit/cacheService.unit with
wctme5.7
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren reopened DERBY-625:
--------------------------------------
changing from fixed to invalid (for derby).
> hang in unit/cacheService.unit with wctme5.7
> --------------------------------------------
>
> Key: DERBY-625
> URL: https://issues.apache.org/jira/browse/DERBY-625
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.1.1.0, 10.2.1.6
> Environment: windows with wctme5.7 (j9 version 2.2)
> Reporter: Myrna van Lunteren
> Priority: Minor
> Attachments: j9_22_hang.breakout
>
>
> Test unit/cacheService.unit hangs with wctme5.7 jvm since June...
> Can someone familiar with services please have a look?
> The hang was not noticed in a timely fashion because our scripts only run with wctme5.7 once a week,
> and for 3 months, our nightly tests took too long to complete - and no one paid attention (me included).
> I've done some historical research on this, but am no closer to deciding if this is a jvm bug exposed by changed derby functionality or a 'new' derby bug exposed by the wctme5.7 (j9 version 2.2) jvm.
> Efforts are hampered by
> - absence of commit archive details between June 13 and July 1
> - svn cannot backtrack to revisions that happened during incubator time
> This is what I found so far:
> - in main
> - the test ran fine on 6/18/2005, but failed on 6/25/2005.
> - From saved commits emails, it appears relevant revisions are between 191353 (jean)
> and 201792 (kathey), jean's are all dita related, 2 of kathey's are functionTests only changes.
> This leaves the following 2
> 201792 - kmarsden - DERBY-389,
> incubator/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
> 191755 - kmarsden - DERBY-8 and DERBY-366; mostly test/master updates, but additionally changed:
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection.java
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection30.java
> - I backtracked the changes from these revisions but still the hang persists...
>
>
> - 10.1
> - I tested build 224373 and 208786 and the could reproduce the hang; but
> with build 190628 (which happened to be stting around on my machine) there was no hang.
> Thus, with 10.1 branch, the problem was introduced/backported between revision
> 190628 and revision 208786.
> - Looking at a combination of the commit archive for July and my saved commit emails, again, most of these are innocent test or dita updates.
> - The following are more interesting:
> - 201659 - satheesh - DERBY-388 -
> incubator/derby/code/branches/10.0/java/engine/org/apache/derby/impl/sql/GenericPreparedStatement.java
> - 208697 - dan - cleanup of published javadoc for embedded jdbc objects
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedConnectionPoolDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDriver.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedSimpleDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedXADataSource.java
> - 208776 - andrew - monster commit backport fixes for DERBY-8, DERBY-247, DERBY-276,
> DERBY-348, DERBY-354,DERBY-361, DERBY-366, DERBY-389, DERBY-405, DERBY-416, and DERBY-420
> - I tried to backtrack my 10.1 branch to revision 208775, but that resulted in:
> svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
> svn:
> Cannot replace a directory from within
> In short, historical research has gotten me nowhere.
> I looked at the stack of the threads when the program is hanging but it tells me nothing either.
> I will attached the stack threads obtained by running the following command:
> j9 -jcl:max -Xbootclasspath/p:c:/ive22/lib/database_enabler.jar;c:ive22/lib/classes.zip org.apache.derbyTesting.unitTests.harness.UnitTestMain
> on windows and subsequently pressing ctrl-break, and derby.log
> Note: this problem does not occur with wsdd5.6 (j9 version 2.1). The test never runs/ran with j9foundation (also wctme5.7).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-625) hang in unit/cacheService.unit with wctme5.7
Posted by "Myrna van Lunteren (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-625?page=all ]
Myrna van Lunteren closed DERBY-625:
------------------------------------
Resolution: Fixed
I had reported the problem to the jvm vendor (IBM) and was informed (and I confirmed) that this JIT problem is fixed in the next release (j9 v 2.3, which is/will be used in ibm's 5.0 / (aka 1.5) jvms). closing.
> hang in unit/cacheService.unit with wctme5.7
> --------------------------------------------
>
> Key: DERBY-625
> URL: http://issues.apache.org/jira/browse/DERBY-625
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0, 10.2.0.0
> Environment: windows with wctme5.7 (j9 version 2.2)
> Reporter: Myrna van Lunteren
> Priority: Minor
> Attachments: j9_22_hang.breakout
>
> Test unit/cacheService.unit hangs with wctme5.7 jvm since June...
> Can someone familiar with services please have a look?
> The hang was not noticed in a timely fashion because our scripts only run with wctme5.7 once a week,
> and for 3 months, our nightly tests took too long to complete - and no one paid attention (me included).
> I've done some historical research on this, but am no closer to deciding if this is a jvm bug exposed by changed derby functionality or a 'new' derby bug exposed by the wctme5.7 (j9 version 2.2) jvm.
> Efforts are hampered by
> - absence of commit archive details between June 13 and July 1
> - svn cannot backtrack to revisions that happened during incubator time
> This is what I found so far:
> - in main
> - the test ran fine on 6/18/2005, but failed on 6/25/2005.
> - From saved commits emails, it appears relevant revisions are between 191353 (jean)
> and 201792 (kathey), jean's are all dita related, 2 of kathey's are functionTests only changes.
> This leaves the following 2
> 201792 - kmarsden - DERBY-389,
> incubator/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
> 191755 - kmarsden - DERBY-8 and DERBY-366; mostly test/master updates, but additionally changed:
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection.java
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection30.java
> - I backtracked the changes from these revisions but still the hang persists...
>
>
> - 10.1
> - I tested build 224373 and 208786 and the could reproduce the hang; but
> with build 190628 (which happened to be stting around on my machine) there was no hang.
> Thus, with 10.1 branch, the problem was introduced/backported between revision
> 190628 and revision 208786.
> - Looking at a combination of the commit archive for July and my saved commit emails, again, most of these are innocent test or dita updates.
> - The following are more interesting:
> - 201659 - satheesh - DERBY-388 -
> incubator/derby/code/branches/10.0/java/engine/org/apache/derby/impl/sql/GenericPreparedStatement.java
> - 208697 - dan - cleanup of published javadoc for embedded jdbc objects
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedConnectionPoolDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDriver.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedSimpleDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedXADataSource.java
> - 208776 - andrew - monster commit backport fixes for DERBY-8, DERBY-247, DERBY-276,
> DERBY-348, DERBY-354,DERBY-361, DERBY-366, DERBY-389, DERBY-405, DERBY-416, and DERBY-420
> - I tried to backtrack my 10.1 branch to revision 208775, but that resulted in:
> svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
> svn:
> Cannot replace a directory from within
> In short, historical research has gotten me nowhere.
> I looked at the stack of the threads when the program is hanging but it tells me nothing either.
> I will attached the stack threads obtained by running the following command:
> j9 -jcl:max -Xbootclasspath/p:c:/ive22/lib/database_enabler.jar;c:ive22/lib/classes.zip org.apache.derbyTesting.unitTests.harness.UnitTestMain
> on windows and subsequently pressing ctrl-break, and derby.log
> Note: this problem does not occur with wsdd5.6 (j9 version 2.1). The test never runs/ran with j9foundation (also wctme5.7).
--
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-625) hang in unit/cacheService.unit with
wctme5.7
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-625?page=comments#action_12418750 ]
Kathey Marsden commented on DERBY-625:
--------------------------------------
There is no component as this is a JVM JIT issue
> hang in unit/cacheService.unit with wctme5.7
> --------------------------------------------
>
> Key: DERBY-625
> URL: http://issues.apache.org/jira/browse/DERBY-625
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0, 10.2.0.0
> Environment: windows with wctme5.7 (j9 version 2.2)
> Reporter: Myrna van Lunteren
> Priority: Minor
> Attachments: j9_22_hang.breakout
>
> Test unit/cacheService.unit hangs with wctme5.7 jvm since June...
> Can someone familiar with services please have a look?
> The hang was not noticed in a timely fashion because our scripts only run with wctme5.7 once a week,
> and for 3 months, our nightly tests took too long to complete - and no one paid attention (me included).
> I've done some historical research on this, but am no closer to deciding if this is a jvm bug exposed by changed derby functionality or a 'new' derby bug exposed by the wctme5.7 (j9 version 2.2) jvm.
> Efforts are hampered by
> - absence of commit archive details between June 13 and July 1
> - svn cannot backtrack to revisions that happened during incubator time
> This is what I found so far:
> - in main
> - the test ran fine on 6/18/2005, but failed on 6/25/2005.
> - From saved commits emails, it appears relevant revisions are between 191353 (jean)
> and 201792 (kathey), jean's are all dita related, 2 of kathey's are functionTests only changes.
> This leaves the following 2
> 201792 - kmarsden - DERBY-389,
> incubator/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
> 191755 - kmarsden - DERBY-8 and DERBY-366; mostly test/master updates, but additionally changed:
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection.java
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection30.java
> - I backtracked the changes from these revisions but still the hang persists...
>
>
> - 10.1
> - I tested build 224373 and 208786 and the could reproduce the hang; but
> with build 190628 (which happened to be stting around on my machine) there was no hang.
> Thus, with 10.1 branch, the problem was introduced/backported between revision
> 190628 and revision 208786.
> - Looking at a combination of the commit archive for July and my saved commit emails, again, most of these are innocent test or dita updates.
> - The following are more interesting:
> - 201659 - satheesh - DERBY-388 -
> incubator/derby/code/branches/10.0/java/engine/org/apache/derby/impl/sql/GenericPreparedStatement.java
> - 208697 - dan - cleanup of published javadoc for embedded jdbc objects
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedConnectionPoolDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDriver.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedSimpleDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedXADataSource.java
> - 208776 - andrew - monster commit backport fixes for DERBY-8, DERBY-247, DERBY-276,
> DERBY-348, DERBY-354,DERBY-361, DERBY-366, DERBY-389, DERBY-405, DERBY-416, and DERBY-420
> - I tried to backtrack my 10.1 branch to revision 208775, but that resulted in:
> svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
> svn:
> Cannot replace a directory from within
> In short, historical research has gotten me nowhere.
> I looked at the stack of the threads when the program is hanging but it tells me nothing either.
> I will attached the stack threads obtained by running the following command:
> j9 -jcl:max -Xbootclasspath/p:c:/ive22/lib/database_enabler.jar;c:ive22/lib/classes.zip org.apache.derbyTesting.unitTests.harness.UnitTestMain
> on windows and subsequently pressing ctrl-break, and derby.log
> Note: this problem does not occur with wsdd5.6 (j9 version 2.1). The test never runs/ran with j9foundation (also wctme5.7).
--
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-625) hang in unit/cacheService.unit with
wctme5.7
Posted by "Myrna van Lunteren (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-625?page=comments#action_12419766 ]
Myrna van Lunteren commented on DERBY-625:
------------------------------------------
I have also seen this with a 64 bit ibm 1.4.2 jvm, which - as indicated by java -version - uses the same j9 v 2.2 as a base. The problem does not occur with the ibm15 on this same machine, so no need to do anything further.
The jvm version that showed the behavior:
Java(TM) 2 Runtime Environment, Standard Edition (build 2.2)
IBM J9SE VM (build 2.2, J2RE 1.4.2 IBM J9 2.2 Linux amd64-64 j9xa64142-20050609
(JIT enabled)
J9VM - 20050524_1742_LHdSMr
JIT - r7_level20050518_1803)
> hang in unit/cacheService.unit with wctme5.7
> --------------------------------------------
>
> Key: DERBY-625
> URL: http://issues.apache.org/jira/browse/DERBY-625
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0, 10.2.0.0
> Environment: windows with wctme5.7 (j9 version 2.2)
> Reporter: Myrna van Lunteren
> Priority: Minor
> Attachments: j9_22_hang.breakout
>
> Test unit/cacheService.unit hangs with wctme5.7 jvm since June...
> Can someone familiar with services please have a look?
> The hang was not noticed in a timely fashion because our scripts only run with wctme5.7 once a week,
> and for 3 months, our nightly tests took too long to complete - and no one paid attention (me included).
> I've done some historical research on this, but am no closer to deciding if this is a jvm bug exposed by changed derby functionality or a 'new' derby bug exposed by the wctme5.7 (j9 version 2.2) jvm.
> Efforts are hampered by
> - absence of commit archive details between June 13 and July 1
> - svn cannot backtrack to revisions that happened during incubator time
> This is what I found so far:
> - in main
> - the test ran fine on 6/18/2005, but failed on 6/25/2005.
> - From saved commits emails, it appears relevant revisions are between 191353 (jean)
> and 201792 (kathey), jean's are all dita related, 2 of kathey's are functionTests only changes.
> This leaves the following 2
> 201792 - kmarsden - DERBY-389,
> incubator/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
> 191755 - kmarsden - DERBY-8 and DERBY-366; mostly test/master updates, but additionally changed:
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection.java
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection30.java
> - I backtracked the changes from these revisions but still the hang persists...
>
>
> - 10.1
> - I tested build 224373 and 208786 and the could reproduce the hang; but
> with build 190628 (which happened to be stting around on my machine) there was no hang.
> Thus, with 10.1 branch, the problem was introduced/backported between revision
> 190628 and revision 208786.
> - Looking at a combination of the commit archive for July and my saved commit emails, again, most of these are innocent test or dita updates.
> - The following are more interesting:
> - 201659 - satheesh - DERBY-388 -
> incubator/derby/code/branches/10.0/java/engine/org/apache/derby/impl/sql/GenericPreparedStatement.java
> - 208697 - dan - cleanup of published javadoc for embedded jdbc objects
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedConnectionPoolDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDriver.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedSimpleDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedXADataSource.java
> - 208776 - andrew - monster commit backport fixes for DERBY-8, DERBY-247, DERBY-276,
> DERBY-348, DERBY-354,DERBY-361, DERBY-366, DERBY-389, DERBY-405, DERBY-416, and DERBY-420
> - I tried to backtrack my 10.1 branch to revision 208775, but that resulted in:
> svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
> svn:
> Cannot replace a directory from within
> In short, historical research has gotten me nowhere.
> I looked at the stack of the threads when the program is hanging but it tells me nothing either.
> I will attached the stack threads obtained by running the following command:
> j9 -jcl:max -Xbootclasspath/p:c:/ive22/lib/database_enabler.jar;c:ive22/lib/classes.zip org.apache.derbyTesting.unitTests.harness.UnitTestMain
> on windows and subsequently pressing ctrl-break, and derby.log
> Note: this problem does not occur with wsdd5.6 (j9 version 2.1). The test never runs/ran with j9foundation (also wctme5.7).
--
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-625) hang in unit/cacheService.unit with
wctme5.7
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-625?page=all ]
Rick Hillegas updated DERBY-625:
--------------------------------
Component: Test
Assigning to Test component.
> hang in unit/cacheService.unit with wctme5.7
> --------------------------------------------
>
> Key: DERBY-625
> URL: http://issues.apache.org/jira/browse/DERBY-625
> Project: Derby
> Type: Bug
> Components: Test
> Versions: 10.1.1.0, 10.2.0.0
> Environment: windows with wctme5.7 (j9 version 2.2)
> Reporter: Myrna van Lunteren
> Priority: Minor
> Attachments: j9_22_hang.breakout
>
> Test unit/cacheService.unit hangs with wctme5.7 jvm since June...
> Can someone familiar with services please have a look?
> The hang was not noticed in a timely fashion because our scripts only run with wctme5.7 once a week,
> and for 3 months, our nightly tests took too long to complete - and no one paid attention (me included).
> I've done some historical research on this, but am no closer to deciding if this is a jvm bug exposed by changed derby functionality or a 'new' derby bug exposed by the wctme5.7 (j9 version 2.2) jvm.
> Efforts are hampered by
> - absence of commit archive details between June 13 and July 1
> - svn cannot backtrack to revisions that happened during incubator time
> This is what I found so far:
> - in main
> - the test ran fine on 6/18/2005, but failed on 6/25/2005.
> - From saved commits emails, it appears relevant revisions are between 191353 (jean)
> and 201792 (kathey), jean's are all dita related, 2 of kathey's are functionTests only changes.
> This leaves the following 2
> 201792 - kmarsden - DERBY-389,
> incubator/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
> 191755 - kmarsden - DERBY-8 and DERBY-366; mostly test/master updates, but additionally changed:
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection.java
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection30.java
> - I backtracked the changes from these revisions but still the hang persists...
>
>
> - 10.1
> - I tested build 224373 and 208786 and the could reproduce the hang; but
> with build 190628 (which happened to be stting around on my machine) there was no hang.
> Thus, with 10.1 branch, the problem was introduced/backported between revision
> 190628 and revision 208786.
> - Looking at a combination of the commit archive for July and my saved commit emails, again, most of these are innocent test or dita updates.
> - The following are more interesting:
> - 201659 - satheesh - DERBY-388 -
> incubator/derby/code/branches/10.0/java/engine/org/apache/derby/impl/sql/GenericPreparedStatement.java
> - 208697 - dan - cleanup of published javadoc for embedded jdbc objects
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedConnectionPoolDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDriver.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedSimpleDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedXADataSource.java
> - 208776 - andrew - monster commit backport fixes for DERBY-8, DERBY-247, DERBY-276,
> DERBY-348, DERBY-354,DERBY-361, DERBY-366, DERBY-389, DERBY-405, DERBY-416, and DERBY-420
> - I tried to backtrack my 10.1 branch to revision 208775, but that resulted in:
> svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
> svn:
> Cannot replace a directory from within
> In short, historical research has gotten me nowhere.
> I looked at the stack of the threads when the program is hanging but it tells me nothing either.
> I will attached the stack threads obtained by running the following command:
> j9 -jcl:max -Xbootclasspath/p:c:/ive22/lib/database_enabler.jar;c:ive22/lib/classes.zip org.apache.derbyTesting.unitTests.harness.UnitTestMain
> on windows and subsequently pressing ctrl-break, and derby.log
> Note: this problem does not occur with wsdd5.6 (j9 version 2.1). The test never runs/ran with j9foundation (also wctme5.7).
--
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-625) hang in unit/cacheService.unit with wctme5.7
Posted by "Myrna van Lunteren (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-625?page=all ]
Myrna van Lunteren updated DERBY-625:
-------------------------------------
Attachment: j9_22_hang.breakout
> hang in unit/cacheService.unit with wctme5.7
> --------------------------------------------
>
> Key: DERBY-625
> URL: http://issues.apache.org/jira/browse/DERBY-625
> Project: Derby
> Type: Bug
> Versions: 10.1.1.0, 10.2.0.0
> Environment: windows with wctme5.7 (j9 version 2.2)
> Reporter: Myrna van Lunteren
> Attachments: j9_22_hang.breakout
>
> Test unit/cacheService.unit hangs with wctme5.7 jvm since June...
> Can someone familiar with services please have a look?
> The hang was not noticed in a timely fashion because our scripts only run with wctme5.7 once a week,
> and for 3 months, our nightly tests took too long to complete - and no one paid attention (me included).
> I've done some historical research on this, but am no closer to deciding if this is a jvm bug exposed by changed derby functionality or a 'new' derby bug exposed by the wctme5.7 (j9 version 2.2) jvm.
> Efforts are hampered by
> - absence of commit archive details between June 13 and July 1
> - svn cannot backtrack to revisions that happened during incubator time
> This is what I found so far:
> - in main
> - the test ran fine on 6/18/2005, but failed on 6/25/2005.
> - From saved commits emails, it appears relevant revisions are between 191353 (jean)
> and 201792 (kathey), jean's are all dita related, 2 of kathey's are functionTests only changes.
> This leaves the following 2
> 201792 - kmarsden - DERBY-389,
> incubator/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
> 191755 - kmarsden - DERBY-8 and DERBY-366; mostly test/master updates, but additionally changed:
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection.java
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection30.java
> - I backtracked the changes from these revisions but still the hang persists...
>
>
> - 10.1
> - I tested build 224373 and 208786 and the could reproduce the hang; but
> with build 190628 (which happened to be stting around on my machine) there was no hang.
> Thus, with 10.1 branch, the problem was introduced/backported between revision
> 190628 and revision 208786.
> - Looking at a combination of the commit archive for July and my saved commit emails, again, most of these are innocent test or dita updates.
> - The following are more interesting:
> - 201659 - satheesh - DERBY-388 -
> incubator/derby/code/branches/10.0/java/engine/org/apache/derby/impl/sql/GenericPreparedStatement.java
> - 208697 - dan - cleanup of published javadoc for embedded jdbc objects
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedConnectionPoolDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDriver.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedSimpleDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedXADataSource.java
> - 208776 - andrew - monster commit backport fixes for DERBY-8, DERBY-247, DERBY-276,
> DERBY-348, DERBY-354,DERBY-361, DERBY-366, DERBY-389, DERBY-405, DERBY-416, and DERBY-420
> - I tried to backtrack my 10.1 branch to revision 208775, but that resulted in:
> svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
> svn:
> Cannot replace a directory from within
> In short, historical research has gotten me nowhere.
> I looked at the stack of the threads when the program is hanging but it tells me nothing either.
> I will attached the stack threads obtained by running the following command:
> j9 -jcl:max -Xbootclasspath/p:c:/ive22/lib/database_enabler.jar;c:ive22/lib/classes.zip org.apache.derbyTesting.unitTests.harness.UnitTestMain
> on windows and subsequently pressing ctrl-break, and derby.log
> Note: this problem does not occur with wsdd5.6 (j9 version 2.1). The test never runs/ran with j9foundation (also wctme5.7).
--
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] Resolved: (DERBY-625) hang in unit/cacheService.unit with
wctme5.7
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren resolved DERBY-625.
--------------------------------------
Resolution: Invalid
> hang in unit/cacheService.unit with wctme5.7
> --------------------------------------------
>
> Key: DERBY-625
> URL: https://issues.apache.org/jira/browse/DERBY-625
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.1.1.0, 10.2.1.6
> Environment: windows with wctme5.7 (j9 version 2.2)
> Reporter: Myrna van Lunteren
> Priority: Minor
> Attachments: j9_22_hang.breakout
>
>
> Test unit/cacheService.unit hangs with wctme5.7 jvm since June...
> Can someone familiar with services please have a look?
> The hang was not noticed in a timely fashion because our scripts only run with wctme5.7 once a week,
> and for 3 months, our nightly tests took too long to complete - and no one paid attention (me included).
> I've done some historical research on this, but am no closer to deciding if this is a jvm bug exposed by changed derby functionality or a 'new' derby bug exposed by the wctme5.7 (j9 version 2.2) jvm.
> Efforts are hampered by
> - absence of commit archive details between June 13 and July 1
> - svn cannot backtrack to revisions that happened during incubator time
> This is what I found so far:
> - in main
> - the test ran fine on 6/18/2005, but failed on 6/25/2005.
> - From saved commits emails, it appears relevant revisions are between 191353 (jean)
> and 201792 (kathey), jean's are all dita related, 2 of kathey's are functionTests only changes.
> This leaves the following 2
> 201792 - kmarsden - DERBY-389,
> incubator/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
> 191755 - kmarsden - DERBY-8 and DERBY-366; mostly test/master updates, but additionally changed:
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection.java
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection30.java
> - I backtracked the changes from these revisions but still the hang persists...
>
>
> - 10.1
> - I tested build 224373 and 208786 and the could reproduce the hang; but
> with build 190628 (which happened to be stting around on my machine) there was no hang.
> Thus, with 10.1 branch, the problem was introduced/backported between revision
> 190628 and revision 208786.
> - Looking at a combination of the commit archive for July and my saved commit emails, again, most of these are innocent test or dita updates.
> - The following are more interesting:
> - 201659 - satheesh - DERBY-388 -
> incubator/derby/code/branches/10.0/java/engine/org/apache/derby/impl/sql/GenericPreparedStatement.java
> - 208697 - dan - cleanup of published javadoc for embedded jdbc objects
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedConnectionPoolDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDriver.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedSimpleDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedXADataSource.java
> - 208776 - andrew - monster commit backport fixes for DERBY-8, DERBY-247, DERBY-276,
> DERBY-348, DERBY-354,DERBY-361, DERBY-366, DERBY-389, DERBY-405, DERBY-416, and DERBY-420
> - I tried to backtrack my 10.1 branch to revision 208775, but that resulted in:
> svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
> svn:
> Cannot replace a directory from within
> In short, historical research has gotten me nowhere.
> I looked at the stack of the threads when the program is hanging but it tells me nothing either.
> I will attached the stack threads obtained by running the following command:
> j9 -jcl:max -Xbootclasspath/p:c:/ive22/lib/database_enabler.jar;c:ive22/lib/classes.zip org.apache.derbyTesting.unitTests.harness.UnitTestMain
> on windows and subsequently pressing ctrl-break, and derby.log
> Note: this problem does not occur with wsdd5.6 (j9 version 2.1). The test never runs/ran with j9foundation (also wctme5.7).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-625) hang in unit/cacheService.unit with
wctme5.7
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren closed DERBY-625.
------------------------------------
> hang in unit/cacheService.unit with wctme5.7
> --------------------------------------------
>
> Key: DERBY-625
> URL: https://issues.apache.org/jira/browse/DERBY-625
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.1.1.0, 10.2.1.6
> Environment: windows with wctme5.7 (j9 version 2.2)
> Reporter: Myrna van Lunteren
> Priority: Minor
> Attachments: j9_22_hang.breakout
>
>
> Test unit/cacheService.unit hangs with wctme5.7 jvm since June...
> Can someone familiar with services please have a look?
> The hang was not noticed in a timely fashion because our scripts only run with wctme5.7 once a week,
> and for 3 months, our nightly tests took too long to complete - and no one paid attention (me included).
> I've done some historical research on this, but am no closer to deciding if this is a jvm bug exposed by changed derby functionality or a 'new' derby bug exposed by the wctme5.7 (j9 version 2.2) jvm.
> Efforts are hampered by
> - absence of commit archive details between June 13 and July 1
> - svn cannot backtrack to revisions that happened during incubator time
> This is what I found so far:
> - in main
> - the test ran fine on 6/18/2005, but failed on 6/25/2005.
> - From saved commits emails, it appears relevant revisions are between 191353 (jean)
> and 201792 (kathey), jean's are all dita related, 2 of kathey's are functionTests only changes.
> This leaves the following 2
> 201792 - kmarsden - DERBY-389,
> incubator/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
> 191755 - kmarsden - DERBY-8 and DERBY-366; mostly test/master updates, but additionally changed:
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection.java
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection30.java
> - I backtracked the changes from these revisions but still the hang persists...
>
>
> - 10.1
> - I tested build 224373 and 208786 and the could reproduce the hang; but
> with build 190628 (which happened to be stting around on my machine) there was no hang.
> Thus, with 10.1 branch, the problem was introduced/backported between revision
> 190628 and revision 208786.
> - Looking at a combination of the commit archive for July and my saved commit emails, again, most of these are innocent test or dita updates.
> - The following are more interesting:
> - 201659 - satheesh - DERBY-388 -
> incubator/derby/code/branches/10.0/java/engine/org/apache/derby/impl/sql/GenericPreparedStatement.java
> - 208697 - dan - cleanup of published javadoc for embedded jdbc objects
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedConnectionPoolDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDriver.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedSimpleDataSource.java
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedXADataSource.java
> - 208776 - andrew - monster commit backport fixes for DERBY-8, DERBY-247, DERBY-276,
> DERBY-348, DERBY-354,DERBY-361, DERBY-366, DERBY-389, DERBY-405, DERBY-416, and DERBY-420
> - I tried to backtrack my 10.1 branch to revision 208775, but that resulted in:
> svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
> svn:
> Cannot replace a directory from within
> In short, historical research has gotten me nowhere.
> I looked at the stack of the threads when the program is hanging but it tells me nothing either.
> I will attached the stack threads obtained by running the following command:
> j9 -jcl:max -Xbootclasspath/p:c:/ive22/lib/database_enabler.jar;c:ive22/lib/classes.zip org.apache.derbyTesting.unitTests.harness.UnitTestMain
> on windows and subsequently pressing ctrl-break, and derby.log
> Note: this problem does not occur with wsdd5.6 (j9 version 2.1). The test never runs/ran with j9foundation (also wctme5.7).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.