Hello Tim,
Thank you for your suggestion. :)
Of course, "fix" is the best choice. I also have tried to use "wait/notify",
but found it didn't work for this case.
Please note that "channel1.read(targetBuf); // Label 3" is a blocking
operation. And we want code at label 1,2 to execute after label 3.
There is the question:
Where should I put "notify"?
1. before "read"? NO. If nofity is put before read, then we still can't
guarantee "configureBlocking" is executed after read.
2. after "read"? NO. read is a blocking operatoin. It will never be executed
if put notify after read.
3. in "read"? Obviously NO.
Please correct me if I'm wrong.
Thanks!
On 7/11/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Andrew Zhang wrote:
> Hello everybody,
>
> I noticed such tests in DatagramChannel, which is useful, but
potentially
> unstable. Consider:
>
> public void testReadWrite_configureBlock() throws Exception {
> byte[] targetArray = new byte[2];
> // bind and connect
> this.channel1.socket().bind(localAddr2);
> this.channel1.connect(localAddr1);
> this.channel2.socket().bind(localAddr1);
> this.channel2.connect(localAddr2);
> ByteBuffer targetBuf = ByteBuffer.wrap(targetArray);
>
> new Thread() {
> public void run() {
> try {
> Thread.sleep(TIME_UNIT);
> channel1.configureBlocking(false); // Label 1
> channel1.close(); // Label 2
> } catch (Exception e) {
> //ignore
> }
> }
> }.start();
> try {
> this.channel1.read(targetBuf); // Label 3
> fail("should throw AsynchronousCloseException");
> } catch (AsynchronousCloseException e) {
> // ok
> }
> }
> This test assumes Label 3 code should execute before Label 1 and Label
2,
> which is right in most cases, because the code invokes "Thread.sleep
> (TIME_UNIT)".
>
> However, it's potentially unstable. It heavily depends on TIME_UNIT
value,
> test environment (Hardware, OS ...)
Urgh. There are *very* few occasions when you need to use
Thread.sleep(); and 'thread synchronization' is definitely not one of
them!
If you have order dependencies between two or more threads then use
wait/notify, or synchronized, and make them explicit.
There are any number of books on multi-threaded programming in Java.
> Indubitably, the test is very useful for testing
> "AsynchronousCloseException" of DatagramChannel.read(ByteBuffer) method.
>
> How shall we deal with such issue? Deleting such valuable tests is not
a
> wise decision, while keeping them may cause build system fail.
>
> One solution I could image is TestNG. :) i.e. Use "@dev" or something to
> mark such tests, say, the tests are only for developing purpose.
>
> Any suggestions?
Fix it! :-)
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew Zhang
China Software Development Lab, IBM
