[
https://issues.apache.org/jira/browse/DERBY-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-4322:
----------------------------------
Assignee: Myrna van Lunteren
Ran derbyall and committed Myrna's patch. I will resolve the issue assuming
this is the problem and it can be reopened if it does not correct the problem.
The theory is that this failure is caused by a problem in the previous test
DerbyNetAutostart which launches a process to start the server and can be left
pinging if the check for the server in the launching process, does not allow
enough time for the server to come up. The pings increment the session number
as seen by runtimeinfo. So the changes are to DerbyNetAutoStart and are to
1) Make sure the server launching process retries enough times for the launched
process comes up.
2) Make sure if something does go wrong, the launched process is destroyed
> 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
> Assignee: 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.
