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)" <ji...@apache.org> on 2010/03/18 00:28:27 UTC
[jira] Updated: (DERBY-4322) intermittent test failure in
derbynet/runtimeinfo
[ https://issues.apache.org/jira/browse/DERBY-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren updated DERBY-4322:
--------------------------------------
Attachment: DERBY-4322.diff
Assuming the problem is really with DerbyNetAutoStart, here's a patch that tries to slow things down and ensure that the server process gets destroyed.
I ran DerbyNetAutoStart (successfully) only so far.
> intermittent test failure in derbynet/runtimeinfo
> -------------------------------------------------
>
> Key: DERBY-4322
> URL: https://issues.apache.org/jira/browse/DERBY-4322
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.5.2.0
> Environment: Linux/VMware with IBM 1.5 or 1.6; IBM iseries (AS 400/ V5R4M0) with IBM 1.6
> Reporter: Myrna van Lunteren
> Attachments: DERBY-4322.diff
>
>
> A few times in regression testing of builds of the 10.5 branch, and also with the testing cycle of 10.5.2.0 on iseries I've seen failures in derbynet/runtimeinfo.
> They look like differences in the Session id and timing differences in return of text to the client.
> For instance, this is with ibm 1.6 on iseries:
> ---------------------------------------
> 5 del
> < Session # :2
> 5a5
> > Session # :52
> 12 del
> < Session # :3
> 12a12
> > Session # :86
> 23 del
> < Session # :2
> 23a23
> > Session # :52
> 32 del
> < Session # :4
> 32a32
> > Session # :88
> 41 del
> < Session # :5
> 41a41
> > Session # :90
> 48 del
> < Session # :6
> 48a48
> > Session # :113
> 58 del
> < Session # :7
> 58a58
> > Session # :117
> ---------------------------------------
> And this is an example of a failure on linux/vmware on 7/15/09 (10.5.1.2 revision: 794133)
> ---------------------------------------
> 5 del
> < Session # :2
> 5a5,6
> > Session # :89
> > Session # :62
> 12d12
> < Session # :3
> 23 del
> < Session # :2
> 23a23
> > Session # :90
> 29a30,38
> > SYSLH0002 VALUES(2)
> > SYSLH0001 SELECT count(*) from sys.systables
> > Session # :62
> > Database :wombat;create=true
> > User :APP
> > # Statements:2
> > Prepared Statement Information:
> > Stmt ID SQLText
> > ------------- -----------
> 32 del
> < Session # :4
> 32a41
> > Session # :92
> 35,43d43
> < # Statements:2
> < Prepared Statement Information:
> < Stmt ID SQLText
> < ------------- -----------
> < SYSLH0002 VALUES(2)
> < SYSLH0001 SELECT count(*) from sys.systables
> < Session # :5
> < Database :wombat;create=true
> < User :APP
> 48 del
> < Session # :6
> 48a48
> > Session # :101
> 58 del
> < Session # :7
> 58a58
> > Session # :108
> ---------------------------------------
> It seems to me these are fairly innocent, and if they are, then possibly the solution is to backport the conversion of runtimeinfo to junit to 10.5. (see DERBY-3834, revisions 792001 and 792254.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.