[
https://issues.apache.org/jira/browse/DERBY-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607704#action_12607704
]
Kathey Marsden commented on DERBY-1764:
---------------------------------------
Thanks Erlend for the new patch. It is looking good. I'd really like someone
else to take a thorough look at the patch though, in case I missed something.
This is an important test and we don't want to lose anything in the translation.
One feature the old stress.multi test had was that if testers became hung, it
would wait for some time for them to complete, dump the thread stack traces and
interrupt the threads. I think the way the test is now if we get a hang, the
test would just hang. Maybe that's ok at least for the first round. That
could be added as an improvement later on.
It would be good if we could test the error handling somehow and make sure
errors are getting reported properly. My only thought on this is to remove
some critical synchronization and introduce a bug to test. Alternately I guess
you could temporarily remove one of the expected SQLStates and let it fail on
that.
StressMulti50x59 used to just run embedded, now I think it will run for
embedded, client and encryption. Is that ok or do the folks that run this test
expect it to run embedded only?
We need to add the test to suites.All, the junit-all ant target and remove it
from derbyall and remove all the old test files. We could check in this
patch and make that a second patch. Let me know if you would like to do it
that way.
Thanks for all the great work. This was a tough test conversion to tackle.
Kathey
> Rewrite stress.multi as a JUnit test
> ------------------------------------
>
> Key: DERBY-1764
> URL: https://issues.apache.org/jira/browse/DERBY-1764
> Project: Derby
> Issue Type: Test
> Components: Test
> Reporter: Knut Anders Hatlen
> Assignee: Erlend Birkenes
> Attachments: DERBY-1764-Review.diff, DERBY-1764-V1.diff
>
>
> Currently, stress.multi consists of a number of sql scripts that are run in
> ij. It often fails with cryptic error messages, and since it uses ij, there
> is often no stack trace. It would be very useful to rewrite the test in JUnit
> so that we can get better error messages and stack traces when it fails.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
