harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: [classlib][nio] How to deal with unstable but useful tests?
Date Wed, 12 Jul 2006 03:23:32 GMT
On 7/12/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>
> Andrew Zhang wrote:
> > On 7/11/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
> >>
> >> I hadn't appreciated that the read call is blocking...
> >>
> >> So how about you do the blocking read() in a new thread, then the main
> >> thread can poll to wait until the reading thread's state is Blocked,
> >> before closing the channel and forcing the exception?
> >>
> >> The problem is that the thread will be detached from the VM and
> blocking
> >> in the OS for the read, so not officially Java Blocked.  You can only
> >> determine OS blocked state via additional native code.
> >>
> >> Therefore, as Paulex wrote, if you are not writing additional native
> >> code for your test you may have to actually synchronize on the reading
> >> thread having passed begin(), not when it is actually read() blocked.
> >
> >
> > Yes. As Paulex suggested,  we have to write implementation test rather
> than
> > api test.
>
> Yes, I think that's right.  I don't see any portable way to detect the
> blocking call in progress, so I don't see how we can make this an API
> test case.  Anyone else have any ideas?
>
> > So is the orignal test valuable? In other words, shall we keep it in api
> > tests?
>
> No, the original delay() version is not going to work when the threads
> are scheduled on different processors.


Thanks Tim. I'll remove these unstable tests from NIO module.

> Does that make sense?
>
> Are you thinking of pursuing an impl test then?


For this specific case, the impl test will be very complicated, because
begin/end are final,

and OSNetworkSystem.getOSNetworkSystem() is static. We need to do lots of
things to inject mocked class into DatagramChannel.read method.

Personally, I'm not inclined to test this method. :) What's your opinion?

Any comments? Thanks!

Regards,
> Tim
>
>
> >> Andrew Zhang wrote:
> >> > 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 <t.p.ellison@gmail.com> 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 (t.p.ellison@gmail.com)
> >> >> IBM Java technology centre, UK.
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> >> For additional commands, e-mail:
> harmony-dev-help@incubator.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >>
> >> Tim Ellison (t.p.ellison@gmail.com)
> >> IBM Java technology centre, UK.
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Andrew Zhang
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message