From cowwoc at bbs.darktech.org Mon Jul 4 13:24:51 2011 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 4 Jul 2011 13:24:51 -0700 (PDT) Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <4DF71F8C.7040800@oracle.com> References: <1307994671919-6471557.post@n2.nabble.com> <4DF672AF.30809@oracle.com> <1307998815455-6471787.post@n2.nabble.com> <1308025303088-6472724.post@n2.nabble.com> <4DF71F8C.7040800@oracle.com> Message-ID: <1309811091219-6547293.post@n2.nabble.com> Alan Bateman-2 wrote: > > cowwoc wrote: >> : >> Also, I think you should push very hard to get this fixed in JDK7. I'd be >> very surprised if Oracle lets you change this part of the specification >> in >> JDK8 because doing so would break backwards-compatibility for existing >> implementations. Better to fix it now before the final spec is published. >> >> > I've created this bug to track it: > > 7054403: (aio spec) IllegalStateExcepiton should be thrown if I/O > operation attempted after timeout > > It's unfortunate that this got forgotten but I think we can fix this > early in jdk8. It helps that the current implementation already throws > IllegalStateException. Furthermore, AsynchronousSocketChannel cannot be > implemented in isolation as it is tied to an > AsynchronousChannelProvider. This means the number of implementations > will likely be very few. Again apologies about this, it was my fault > that this got forgotten. > > -Alan. > Now I'm getting really worried... I just noticed that socket timeouts are wrong as well! If you recall, we had agreed that a timeout value of 0 or less should mean "no timeout" and Long.MAX_VALUE should mean "wait forever": http://web.archiveorange.com/archive/v/gpYtBv5dfSke8QjCflUY But according to http://download.oracle.com/javase/7/docs/api/java/nio/channels/AsynchronousSocketChannel.html "All methods that accept timeout parameters treat values less than or equal to zero to mean that the I/O operation does not timeout." I'm especially worried that unless we fix this in JDK7 it will be impossible to do so in JDK8 due to backwards compatibility concerns. Please say you can fix this in time for JDK7! Thanks, Gili -- View this message in context: http://nio-dev.3157472.n2.nabble.com/AsynchronousSocketChannel-still-throws-unspecified-exception-tp6471557p6547293.html Sent from the nio-dev mailing list archive at Nabble.com. From cowwoc at bbs.darktech.org Wed Jul 6 06:55:57 2011 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 6 Jul 2011 06:55:57 -0700 (PDT) Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <1309811091219-6547293.post@n2.nabble.com> References: <1307994671919-6471557.post@n2.nabble.com> <4DF672AF.30809@oracle.com> <1307998815455-6471787.post@n2.nabble.com> <1308025303088-6472724.post@n2.nabble.com> <4DF71F8C.7040800@oracle.com> <1309811091219-6547293.post@n2.nabble.com> Message-ID: <1309960557104-6554472.post@n2.nabble.com> cowwoc wrote: > > > Alan Bateman-2 wrote: >> >> cowwoc wrote: >>> : >>> Also, I think you should push very hard to get this fixed in JDK7. I'd >>> be >>> very surprised if Oracle lets you change this part of the specification >>> in >>> JDK8 because doing so would break backwards-compatibility for existing >>> implementations. Better to fix it now before the final spec is >>> published. >>> >>> >> I've created this bug to track it: >> >> 7054403: (aio spec) IllegalStateExcepiton should be thrown if I/O >> operation attempted after timeout >> >> It's unfortunate that this got forgotten but I think we can fix this >> early in jdk8. It helps that the current implementation already throws >> IllegalStateException. Furthermore, AsynchronousSocketChannel cannot be >> implemented in isolation as it is tied to an >> AsynchronousChannelProvider. This means the number of implementations >> will likely be very few. Again apologies about this, it was my fault >> that this got forgotten. >> >> -Alan. >> > > Now I'm getting really worried... I just noticed that socket timeouts are > wrong as well! > > If you recall, we had agreed that a timeout value of 0 or less should mean > "no timeout" and Long.MAX_VALUE should mean "wait forever": > http://web.archiveorange.com/archive/v/gpYtBv5dfSke8QjCflUY > > But according to > http://download.oracle.com/javase/7/docs/api/java/nio/channels/AsynchronousSocketChannel.html > "All methods that accept timeout parameters treat values less than or > equal to zero to mean that the I/O operation does not timeout." > > I'm especially worried that unless we fix this in JDK7 it will be > impossible to do so in JDK8 due to backwards compatibility concerns. > Please say you can fix this in time for JDK7! > > Thanks, > Gili > Alan, I've filed http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7063249 Another two reasons I believe this must be fixed is that the existing specification makes it impossible to: 1. Ask the channel to return whatever data it has without waiting 2. As a consequence of #1, you can't ask the channel if it's in an error state without reading at least one byte As you said two years ago, "It's a pity we can't do anything with the existing APIs." I really hope we don't have to say the same about AsynchronousSocketChannel a few years from now... Kind Regards, Gili -- View this message in context: http://nio-dev.3157472.n2.nabble.com/AsynchronousSocketChannel-still-throws-unspecified-exception-tp6471557p6554472.html Sent from the nio-dev mailing list archive at Nabble.com. From cowwoc at bbs.darktech.org Mon Jul 11 06:42:30 2011 From: cowwoc at bbs.darktech.org (cowwoc) Date: Mon, 11 Jul 2011 06:42:30 -0700 (PDT) Subject: Question about AsynchronousByteChannel.read() Message-ID: <1310391750347-6570959.post@n2.nabble.com> Hi, According to the Javadoc of read(ByteBuffer, A, CompletionHandler<Integer,? super A>): "This method may be invoked at any time. Some channel types may not allow more than one read to be outstanding at any given time. If a thread initiates a read operation before a previous read operation has completed then a ReadPendingException will be thrown." On the one hand you're indicating that that some channels support *do* multiple read requests. On the other hand you're saying if multiple requests are issued, ReadPendingException will be thrown. Did you mean to imply that ReadPendingException will only be thrown if the channel implementation does *not* support multiple reads but in other channel implementations it might work just fine? Thanks, Gili -- View this message in context: http://nio-dev.3157472.n2.nabble.com/Question-about-AsynchronousByteChannel-read-tp6570959p6570959.html Sent from the nio-dev mailing list archive at Nabble.com. From Alan.Bateman at oracle.com Wed Jul 13 01:31:25 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Jul 2011 09:31:25 +0100 Subject: Question about AsynchronousByteChannel.read() In-Reply-To: <1310391750347-6570959.post@n2.nabble.com> References: <1310391750347-6570959.post@n2.nabble.com> Message-ID: <4E1D57DD.6030104@oracle.com> cowwoc wrote: > Hi, > > According to the Javadoc of read(ByteBuffer, A, > CompletionHandler<Integer,? super A>): > > "This method may be invoked at any time. Some channel types may not allow > more than one read to be outstanding at any given time. If a thread > initiates a read operation before a previous read operation has completed > then a ReadPendingException will be thrown." > > On the one hand you're indicating that that some channels support *do* > multiple read requests. On the other hand you're saying if multiple requests > are issued, ReadPendingException will be thrown. > > Did you mean to imply that ReadPendingException will only be thrown if the > channel implementation does *not* support multiple reads but in other > channel implementations it might work just fine? > Yes, it depends on the channel type. With a channel to a stream oriented connection then it doesn't always make sense to have more than one outstanding I/O operations of a given type as they would complete in an undefined order (and with an operation such as write then it would easily "corrupt" the stream for example). However it does make sense for other channel types, for example AsynchronousFileChannel where there may be I/O operations to different parts of the file happening at the same thing. If you go back through the archives of this list then you should find some prior discussion on queuing of I/O operations that make be useful to you. -Alan. From Alan.Bateman at oracle.com Wed Jul 13 01:55:26 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Jul 2011 09:55:26 +0100 Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <1309811091219-6547293.post@n2.nabble.com> References: <1307994671919-6471557.post@n2.nabble.com> <4DF672AF.30809@oracle.com> <1307998815455-6471787.post@n2.nabble.com> <1308025303088-6472724.post@n2.nabble.com> <4DF71F8C.7040800@oracle.com> <1309811091219-6547293.post@n2.nabble.com> Message-ID: <4E1D5D7E.1050001@oracle.com> cowwoc wrote: > : > Now I'm getting really worried... I just noticed that socket timeouts are > wrong as well! > > If you recall, we had agreed that a timeout value of 0 or less should mean > "no timeout" and Long.MAX_VALUE should mean "wait forever": > http://web.archiveorange.com/archive/v/gpYtBv5dfSke8QjCflUY > Yes, I remember that discussion and we changed it, via 6878369, so that <= 0 means that the I/O operation doesn't have a timeout (previously it was specified to throw IllegalArgumentException if a negative timeout was specified). -Alan. From Alan.Bateman at oracle.com Wed Jul 13 04:44:22 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Jul 2011 12:44:22 +0100 Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <1309960557104-6554472.post@n2.nabble.com> References: <1307994671919-6471557.post@n2.nabble.com> <4DF672AF.30809@oracle.com> <1307998815455-6471787.post@n2.nabble.com> <1308025303088-6472724.post@n2.nabble.com> <4DF71F8C.7040800@oracle.com> <1309811091219-6547293.post@n2.nabble.com> <1309960557104-6554472.post@n2.nabble.com> Message-ID: <4E1D8516.1010608@oracle.com> cowwoc wrote: > : > Alan, > > I've filed http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7063249 > > Another two reasons I believe this must be fixed is that the existing > specification makes it impossible to: > > 1. Ask the channel to return whatever data it has without waiting > 2. As a consequence of #1, you can't ask the channel if it's in an error > state without reading at least one byte > Just to clarify, the methods that take a timeout do not wait. They are asynchronous like the other read/write methods and it's just a case that the I/O operations may have an associated timeout. If I understand your most recent mails then what you are asking for a way to read/write where the I/O operation is guaranteed to complete immediately, an asynchronous equivalent to a synchronous read/write where the channel is configured non-blocking. This would require a bit of consideration. It would clearly be more expensive, at least for implementations where the underlying I/O is blocking or asynchronous as such implementations would need to first poll the socket. An alternative, at least for the read case, is an "available" method. -Alan. From cowwoc at bbs.darktech.org Wed Jul 13 05:18:20 2011 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 13 Jul 2011 05:18:20 -0700 (PDT) Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <4E1D5D7E.1050001@oracle.com> References: <1307994671919-6471557.post@n2.nabble.com> <4DF672AF.30809@oracle.com> <1307998815455-6471787.post@n2.nabble.com> <1308025303088-6472724.post@n2.nabble.com> <4DF71F8C.7040800@oracle.com> <1309811091219-6547293.post@n2.nabble.com> <4E1D5D7E.1050001@oracle.com> Message-ID: <1310559500455-6578786.post@n2.nabble.com> Alan Bateman-2 wrote: > > cowwoc wrote: >> : >> Now I'm getting really worried... I just noticed that socket timeouts are >> wrong as well! >> >> If you recall, we had agreed that a timeout value of 0 or less should >> mean >> "no timeout" and Long.MAX_VALUE should mean "wait forever": >> http://web.archiveorange.com/archive/v/gpYtBv5dfSke8QjCflUY >> > Yes, I remember that discussion and we changed it, via 6878369, so that > <= 0 means that the I/O operation doesn't have a timeout (previously it > was specified to throw IllegalArgumentException if a negative timeout > was specified). > > -Alan. > I'm a bit confused. Why does http://download.oracle.com/javase/7/docs/api/java/nio/channels/AsynchronousSocketChannel.html still read "All methods that accept timeout parameters treat values less than or equal to zero to mean that the I/O operation does not timeout"? This looks like the final JDK7 documentation. To me, "does not timeout" means "waits forever". Is this a simple documentation bug? Alan Bateman-2 wrote: > > Just to clarify, the methods that take a timeout do not wait. They are > asynchronous like the other read/write methods and it's just a case that > the I/O operations may have an associated timeout. If I understand your > most recent mails then what you are asking for a way to read/write where > the I/O operation is guaranteed to complete immediately, an asynchronous > equivalent to a synchronous read/write where the channel is configured > non-blocking. This would require a bit of consideration. It would > clearly be more expensive, at least for implementations where the > underlying I/O is blocking or asynchronous as such implementations would > need to first poll the socket. An alternative, at least for the read > case, is an "available" method. > Fortunately, that's not what I meant. Looking at AsynchronousSocketChannelImpl I am asking for similar handling as "!hasSpaceToRead". If timeout <= 0 and we're returning a Future, set the value immediately and return the Future. If timeout <= 0 and we're returning a CompletionHandler, use Invoker.invoke() to fire an already-computed response. Does the existing implementation behave this way? Would it be a simple matter to add this? Thanks, Gili -- View this message in context: http://nio-dev.3157472.n2.nabble.com/AsynchronousSocketChannel-still-throws-unspecified-exception-tp6471557p6578786.html Sent from the nio-dev mailing list archive at Nabble.com. From Alan.Bateman at oracle.com Wed Jul 13 06:40:07 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Jul 2011 14:40:07 +0100 Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <1310559500455-6578786.post@n2.nabble.com> References: <1307994671919-6471557.post@n2.nabble.com> <4DF672AF.30809@oracle.com> <1307998815455-6471787.post@n2.nabble.com> <1308025303088-6472724.post@n2.nabble.com> <4DF71F8C.7040800@oracle.com> <1309811091219-6547293.post@n2.nabble.com> <4E1D5D7E.1050001@oracle.com> <1310559500455-6578786.post@n2.nabble.com> Message-ID: <4E1DA037.7060202@oracle.com> cowwoc wrote: > : > I'm a bit confused. Why does > http://download.oracle.com/javase/7/docs/api/java/nio/channels/AsynchronousSocketChannel.html > still read "All methods that accept timeout parameters treat values less > than or equal to zero to mean that the I/O operation does not timeout"? This > looks like the final JDK7 documentation. > > To me, "does not timeout" means "waits forever". Is this a simple > documentation bug? > The read/write operations in this API are asynchronous. They are not synchronous and do not wait, irrespective of the timeout values. So when it says "does not timeout" it just means that the I/O operations do not have an associated timeout. If you invoke the read/write methods then the methods will complete immediately but the I/O operation will only complete when bytes are actually read or written (so exactly the same as the read/write methods that AsynchronousByteChannel defines). > : > > Fortunately, that's not what I meant. Looking at > AsynchronousSocketChannelImpl I am asking for similar handling as > "!hasSpaceToRead". If timeout <= 0 and we're returning a Future, set the > value immediately and return the Future. If timeout <= 0 and we're returning > a CompletionHandler, use Invoker.invoke() to fire an already-computed > response. > This requires a result, which is why I suggested it would require polling the socket and if not readable (or writable, depending) then the I/O operation would complete with a result of 0 (which is essentially an asynchronous equivalent of synchronous read/write with the channel configured non-blocking). > Does the existing implementation behave this way? Would it be a simple > matter to add this? > No, it doesn't work this way and would require some consideration before going down that route. -Alan. From cowwoc at bbs.darktech.org Wed Jul 13 08:04:18 2011 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 13 Jul 2011 08:04:18 -0700 (PDT) Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <4E1DA037.7060202@oracle.com> References: <1307994671919-6471557.post@n2.nabble.com> <4DF672AF.30809@oracle.com> <1307998815455-6471787.post@n2.nabble.com> <1308025303088-6472724.post@n2.nabble.com> <4DF71F8C.7040800@oracle.com> <1309811091219-6547293.post@n2.nabble.com> <4E1D5D7E.1050001@oracle.com> <1310559500455-6578786.post@n2.nabble.com> <4E1DA037.7060202@oracle.com> Message-ID: <1310569458197-6579342.post@n2.nabble.com> Alan Bateman-2 wrote: > > The read/write operations in this API are asynchronous. They are not > synchronous and do not wait, irrespective of the timeout values. So when > it says "does not timeout" it just means that the I/O operations do not > have an associated timeout. If you invoke the read/write methods then > the methods will complete immediately but the I/O operation will only > complete when bytes are actually read or written (so exactly the same as > the read/write methods that AsynchronousByteChannel defines). > I am fairly sure I am misunderstanding what you wrote above, because it seems to contradict our discussion at http://web.archiveorange.com/archive/v/gpYtBv5dfSke8QjCflUY When you say "does not timeout" it means to me "blocks forever until bytes come in". But if you read our original discussion (in the above link) "no timeout" meant "returns right away if there are no bytes available". I'm going to break this down again to make sure we understand each other. We have: 1. A read() method 2. The actual read operation, let's call it readImpl() My expectation is that: 1. Regardless of what timeout value a user passes into read() it always returns right away. 2. When the user passes a positive timeout value, readImpl() will return any available bytes without issuing a read on the underlying file/socket handle. If no bytes are available it will issue a read on the underlying file/socket handle and wait up to [timeout] milliseconds for bytes to come in before throwing a timeout exception. 3. When the user passes a timeout <= 0, readImpl() return any available bytes (without issuing a read on the underlying file/socket handle). If no bytes are available, it will return 0 bytes read. Now, how does this compare to the actual implementation? What is the current behavior? Alan Bateman-2 wrote: > > This requires a result, which is why I suggested it would require > polling the socket and if not readable (or writable, depending) then the > I/O operation would complete with a result of 0 (which is essentially an > asynchronous equivalent of synchronous read/write with the channel > configured non-blocking). > I understand. Thank you, Gili -- View this message in context: http://nio-dev.3157472.n2.nabble.com/AsynchronousSocketChannel-still-throws-unspecified-exception-tp6471557p6579342.html Sent from the nio-dev mailing list archive at Nabble.com. From Alan.Bateman at oracle.com Wed Jul 13 08:51:37 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Jul 2011 16:51:37 +0100 Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <1310569458197-6579342.post@n2.nabble.com> References: <1307994671919-6471557.post@n2.nabble.com> <4DF672AF.30809@oracle.com> <1307998815455-6471787.post@n2.nabble.com> <1308025303088-6472724.post@n2.nabble.com> <4DF71F8C.7040800@oracle.com> <1309811091219-6547293.post@n2.nabble.com> <4E1D5D7E.1050001@oracle.com> <1310559500455-6578786.post@n2.nabble.com> <4E1DA037.7060202@oracle.com> <1310569458197-6579342.post@n2.nabble.com> Message-ID: <4E1DBF09.30208@oracle.com> cowwoc wrote: > : > I am fairly sure I am misunderstanding what you wrote above, because it > seems to contradict our discussion at > http://web.archiveorange.com/archive/v/gpYtBv5dfSke8QjCflUY > > When you say "does not timeout" it means to me "blocks forever until bytes > come in". But if you read our original discussion (in the above link) "no > timeout" meant "returns right away if there are no bytes available". > > I'm going to break this down again to make sure we understand each other. We > have: > > 1. A read() method > 2. The actual read operation, let's call it readImpl() > > My expectation is that: > 1. Regardless of what timeout value a user passes into read() it always > returns right away. > Yep. > 2. When the user passes a positive timeout value, readImpl() will return any > available bytes without issuing a read on the underlying file/socket handle. > If no bytes are available it will issue a read on the underlying file/socket > handle and wait up to [timeout] milliseconds for bytes to come in before > throwing a timeout exception. > Reading the "available bytes" requires reading from the socket so a read will be initiated. If it completes before the timeout has elapsed then the timer will be cancelled. > 3. When the user passes a timeout <= 0, readImpl() return any available > bytes (without issuing a read on the underlying file/socket handle). If no > bytes are available, it will return 0 bytes read. > > Now, how does this compare to the actual implementation? What is the current > behavior? > As it stands, if the timeout is <= 0 then it means there isn't any timeout. If there are available bytes or we're at end of stream then the read operation will complete immediately (meaning the completion handler will be invoked immediately). Otherwise the read will only complete when bytes arrive, the peer closes the connection, or some error occurs. This is how it is both specified and implemented. So where we mostly differ is at 3 where I think you are arguing that <= 0 is a read that is guaranteed to complete immediately. We don't have today and would require a bit of consideration to ensure that (a) it is actually needed, and (b) what the API would be. -Alan. From cowwoc at bbs.darktech.org Wed Jul 13 09:41:43 2011 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 13 Jul 2011 12:41:43 -0400 Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <4E1DBF09.30208@oracle.com> References: <1307994671919-6471557.post@n2.nabble.com> <4DF672AF.30809@oracle.com> <1307998815455-6471787.post@n2.nabble.com> <1308025303088-6472724.post@n2.nabble.com> <4DF71F8C.7040800@oracle.com> <1309811091219-6547293.post@n2.nabble.com> <4E1D5D7E.1050001@oracle.com> <1310559500455-6578786.post@n2.nabble.com> <4E1DA037.7060202@oracle.com> <1310569458197-6579342.post@n2.nabble.com> <4E1DBF09.30208@oracle.com> Message-ID: <4E1DCAC7.6030804@bbs.darktech.org> On 13/07/2011 11:51 AM, Alan Bateman wrote: >> 3. When the user passes a timeout <= 0, readImpl() return any available >> bytes (without issuing a read on the underlying file/socket handle). >> If no >> bytes are available, it will return 0 bytes read. >> >> Now, how does this compare to the actual implementation? What is the >> current >> behavior? > As it stands, if the timeout is <= 0 then it means there isn't any > timeout. If there are available bytes or we're at end of stream then > the read operation will complete immediately (meaning the completion > handler will be invoked immediately). Otherwise the read will only > complete when bytes arrive, the peer closes the connection, or some > error occurs. This is how it is both specified and implemented. > > So where we mostly differ is at 3 where I think you are arguing that > <= 0 is a read that is guaranteed to complete immediately. We don't > have today and would require a bit of consideration to ensure that (a) > it is actually needed, and (b) what the API would be. Okay, but this contradicts our original discussion and how j.u.c works (which we're trying to be consistent with). I'll give you a simple example. If I invoke CountDownLatch.await(0, TimeUnit.MILLISECONDS) the specification reads "If the current count is zero then this method returns immediately." So first of all we've established that a timeout of zero should never block. The next example demonstrates how a timeout of zero can be used to poll a value. If I invoke ReentrantLock.tryLock(0, TimeUnit.MILLISECONDS) it tries acquiring the lock without waiting. If the lock is not immediately available, it returns false. If it is immediately available, it establishes the lock and returns true. That's my interpretation based on http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/ReentrantLock.html#tryLock%28%29 's discussion of "if you want to honor the fairness setting for this lock". > Reading the "available bytes" requires reading from the socket so a > read will be initiated. If it completes before the timeout has elapsed > then the timer will be cancelled. I understand but I expect this to work similar to ReentrantLock.tryLock(0, TimeUnit). If available() >= 0 then it should return all available bytes immediately regardless of what the timeout value is. I believe you simply need to invoke available() before beginning a read. If it returns a non-zero value, disable the timeout and read forever (the OS guarantees this should return instantaneously). Gili From cowwoc at bbs.darktech.org Wed Jul 13 10:02:10 2011 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 13 Jul 2011 10:02:10 -0700 (PDT) Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <4E1DCAC7.6030804@bbs.darktech.org> References: <1307998815455-6471787.post@n2.nabble.com> <1308025303088-6472724.post@n2.nabble.com> <4DF71F8C.7040800@oracle.com> <1309811091219-6547293.post@n2.nabble.com> <4E1D5D7E.1050001@oracle.com> <1310559500455-6578786.post@n2.nabble.com> <4E1DA037.7060202@oracle.com> <1310569458197-6579342.post@n2.nabble.com> <4E1DBF09.30208@oracle.com> <4E1DCAC7.6030804@bbs.darktech.org> Message-ID: <1310576530200-6579825.post@n2.nabble.com> cowwoc wrote: > > On 13/07/2011 11:51 AM, Alan Bateman wrote: >>> 3. When the user passes a timeout <= 0, readImpl() return any available >>> bytes (without issuing a read on the underlying file/socket handle). >>> If no >>> bytes are available, it will return 0 bytes read. >>> >>> Now, how does this compare to the actual implementation? What is the >>> current >>> behavior? >> As it stands, if the timeout is <= 0 then it means there isn't any >> timeout. If there are available bytes or we're at end of stream then >> the read operation will complete immediately (meaning the completion >> handler will be invoked immediately). Otherwise the read will only >> complete when bytes arrive, the peer closes the connection, or some >> error occurs. This is how it is both specified and implemented. >> >> So where we mostly differ is at 3 where I think you are arguing that >> <= 0 is a read that is guaranteed to complete immediately. We don't >> have today and would require a bit of consideration to ensure that (a) >> it is actually needed, and (b) what the API would be. > > Okay, but this contradicts our original discussion and how j.u.c > works (which we're trying to be consistent with). I'll give you a simple > example. If I invoke CountDownLatch.await(0, TimeUnit.MILLISECONDS) the > specification reads "If the current count is zero then this method > returns immediately." So first of all we've established that a timeout > of zero should never block. > > The next example demonstrates how a timeout of zero can be used to > poll a value. If I invoke ReentrantLock.tryLock(0, > TimeUnit.MILLISECONDS) it tries acquiring the lock without waiting. If > the lock is not immediately available, it returns false. If it is > immediately available, it establishes the lock and returns true. That's > my interpretation based on > http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/ReentrantLock.html#tryLock%28%29 > 's discussion of "if you want to honor the fairness setting for this > lock". > >> Reading the "available bytes" requires reading from the socket so a >> read will be initiated. If it completes before the timeout has elapsed >> then the timer will be cancelled. > > I understand but I expect this to work similar to > ReentrantLock.tryLock(0, TimeUnit). If available() >= 0 then it should > return all available bytes immediately regardless of what the timeout > value is. I believe you simply need to invoke available() before > beginning a read. If it returns a non-zero value, disable the timeout > and read forever (the OS guarantees this should return instantaneously). > > Gili > As for why we need this, quoting http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7063249: 1. Consistency with java.util.concurrent 2. Common sense (waiting 0 means not waiting at all) 3. It makes waits composable: void composite(timeLimit) { ... step1(timeLimit); ... step2(timeLimit - elapsed); } which otherwise can surprisingly misbehave if timeLimit - elapsed happens to be 0. 4. Without this change, there is no way to ask a channel to return existing data without waiting. 5. Without this change, there is no way of checking whether the channel is in an "error state" without reading at least one byte (in case it is not in the error state). Gili -- View this message in context: http://nio-dev.3157472.n2.nabble.com/AsynchronousSocketChannel-still-throws-unspecified-exception-tp6471557p6579825.html Sent from the nio-dev mailing list archive at Nabble.com. From Alan.Bateman at oracle.com Wed Jul 13 10:34:47 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Jul 2011 18:34:47 +0100 Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <4E1DCAC7.6030804@bbs.darktech.org> References: <1307994671919-6471557.post@n2.nabble.com> <4DF672AF.30809@oracle.com> <1307998815455-6471787.post@n2.nabble.com> <1308025303088-6472724.post@n2.nabble.com> <4DF71F8C.7040800@oracle.com> <1309811091219-6547293.post@n2.nabble.com> <4E1D5D7E.1050001@oracle.com> <1310559500455-6578786.post@n2.nabble.com> <4E1DA037.7060202@oracle.com> <1310569458197-6579342.post@n2.nabble.com> <4E1DBF09.30208@oracle.com> <4E1DCAC7.6030804@bbs.darktech.org> Message-ID: <4E1DD737.9010800@oracle.com> cowwoc wrote: > : > Okay, but this contradicts our original discussion and how j.u.c > works (which we're trying to be consistent with). I'll give you a > simple example. If I invoke CountDownLatch.await(0, > TimeUnit.MILLISECONDS) the specification reads "If the current count > is zero then this method returns immediately." So first of all we've > established that a timeout of zero should never block. This is a wait timeout, meaning that CountDownLatch.await will block/wait when a timeout is specified (assuming the latch hasn't counted down). So if this were a synchronous I/O API then all would be clear. With an asynchronous I/O API then the read/write methods never block/wait. The timeout is instead associated with the I/O operation to support error handling in the event that the peer does not respond. The > 0 case should be clear, the <= 0 is less clear and is currently specified (and implemented) to work like the read/write methods that doesn't have timeout parameters. Translating this into synchronous terms then it's equivalent to await(). > >> Reading the "available bytes" requires reading from the socket so a >> read will be initiated. If it completes before the timeout has >> elapsed then the timer will be cancelled. > > I understand but I expect this to work similar to > ReentrantLock.tryLock(0, TimeUnit). If available() >= 0 then it should > return all available bytes immediately regardless of what the timeout > value is. I believe you simply need to invoke available() before > beginning a read. If it returns a non-zero value, disable the timeout > and read forever (the OS guarantees this should return instantaneously). For socket I/O (AsynchronousSocketChannel) this would be expensive. I think what we need to establish is whether this is really needed, and if so, what is the API. Possible API approaches would be a channel mode (configureImmediateMode/equivalent), new readNow/writeNow methods, or even an "available" method. -Alan. From cowwoc at bbs.darktech.org Wed Jul 13 11:27:36 2011 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 13 Jul 2011 14:27:36 -0400 Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <4E1DD737.9010800@oracle.com> References: <1307994671919-6471557.post@n2.nabble.com> <4DF672AF.30809@oracle.com> <1307998815455-6471787.post@n2.nabble.com> <1308025303088-6472724.post@n2.nabble.com> <4DF71F8C.7040800@oracle.com> <1309811091219-6547293.post@n2.nabble.com> <4E1D5D7E.1050001@oracle.com> <1310559500455-6578786.post@n2.nabble.com> <4E1DA037.7060202@oracle.com> <1310569458197-6579342.post@n2.nabble.com> <4E1DBF09.30208@oracle.com> <4E1DCAC7.6030804@bbs.darktech.org> <4E1DD737.9010800@oracle.com> Message-ID: <4E1DE398.1060302@bbs.darktech.org> On 13/07/2011 1:34 PM, Alan Bateman wrote: > cowwoc wrote: >> : >> Okay, but this contradicts our original discussion and how j.u.c >> works (which we're trying to be consistent with). I'll give you a >> simple example. If I invoke CountDownLatch.await(0, >> TimeUnit.MILLISECONDS) the specification reads "If the current count >> is zero then this method returns immediately." So first of all we've >> established that a timeout of zero should never block. > This is a wait timeout, meaning that CountDownLatch.await will > block/wait when a timeout is specified (assuming the latch hasn't > counted down). So if this were a synchronous I/O API then all would be > clear. > > With an asynchronous I/O API then the read/write methods never > block/wait. The timeout is instead associated with the I/O operation > to support error handling in the event that the peer does not respond. > The > 0 case should be clear, the <= 0 is less clear and is currently > specified (and implemented) to work like the read/write methods that > doesn't have timeout parameters. Translating this into synchronous > terms then it's equivalent to await(). I don't see why the <= 0 case is less clear. The way I see it, read() is an asynchronous layer on top of a synchronous readImpl() API. If we're saying that timeout <= 0 means "return immediately" then surely readImpl(timeout<=0) should return right away. read() isn't part of the equation because (as we both agree) the timeouts are really parameters for readImpl(), not read(). >> I understand but I expect this to work similar to >> ReentrantLock.tryLock(0, TimeUnit). If available() >= 0 then it >> should return all available bytes immediately regardless of what the >> timeout value is. I believe you simply need to invoke available() >> before beginning a read. If it returns a non-zero value, disable the >> timeout and read forever (the OS guarantees this should return >> instantaneously). > For socket I/O (AsynchronousSocketChannel) this would be expensive. I > think what we need to establish is whether this is really needed, and > if so, what is the API. Possible API approaches would be a channel > mode (configureImmediateMode/equivalent), new readNow/writeNow > methods, or even an "available" method. I think it's needed for the reasons I mentioned here: http://nio-dev.3157472.n2.nabble.com/AsynchronousSocketChannel-still-throws-unspecified-exception-tp6471557p6579825.html I'm against adding a separate method (instead of timeout of zero meaning "return immediately") because: 1. It won't be consistent with java.util.concurrent 2. It causes problems when users compose timeouts: void composite(timeLimit) { ... step1(timeLimit); ... step2(timeLimit - elapsed); } if (timeLimit - elapsed) happens to be <= 0 all of a sudden the call blocks forever instead of waiting the remaining amount of time. Gili From Alan.Bateman at oracle.com Wed Jul 13 11:48:11 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Jul 2011 19:48:11 +0100 Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <4E1DE398.1060302@bbs.darktech.org> References: <1307994671919-6471557.post@n2.nabble.com> <4DF672AF.30809@oracle.com> <1307998815455-6471787.post@n2.nabble.com> <1308025303088-6472724.post@n2.nabble.com> <4DF71F8C.7040800@oracle.com> <1309811091219-6547293.post@n2.nabble.com> <4E1D5D7E.1050001@oracle.com> <1310559500455-6578786.post@n2.nabble.com> <4E1DA037.7060202@oracle.com> <1310569458197-6579342.post@n2.nabble.com> <4E1DBF09.30208@oracle.com> <4E1DCAC7.6030804@bbs.darktech.org> <4E1DD737.9010800@oracle.com> <4E1DE398.1060302@bbs.darktech.org> Message-ID: <4E1DE86B.6030501@oracle.com> cowwoc wrote: > > I don't see why the <= 0 case is less clear. The way I see it, > read() is an asynchronous layer on top of a synchronous readImpl() > API. If we're saying that timeout <= 0 means "return immediately" then > surely readImpl(timeout<=0) should return right away. read() isn't > part of the equation because (as we both agree) the timeouts are > really parameters for readImpl(), not read(). It's not generally a layer over a synchronous API in blocking mode as that would be problematic when there are tens of thousands of connections. The timeout is also not generally something that the underlying implementation knows about either. It could do in some implementations but it is more likely to be an add-on with the underlying implementation making use of the operating system's asynchronous I/O support or maybe be based on non-blocking I/O. All I can say is that we can look at this for jdk8 and decide whether we need this and what the API should be. We can use 7063249 that you created to track it. -Alan. From cowwoc at bbs.darktech.org Wed Jul 13 13:15:46 2011 From: cowwoc at bbs.darktech.org (cowwoc) Date: Wed, 13 Jul 2011 13:15:46 -0700 (PDT) Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <4E1DE86B.6030501@oracle.com> References: <1309811091219-6547293.post@n2.nabble.com> <4E1D5D7E.1050001@oracle.com> <1310559500455-6578786.post@n2.nabble.com> <4E1DA037.7060202@oracle.com> <1310569458197-6579342.post@n2.nabble.com> <4E1DBF09.30208@oracle.com> <4E1DCAC7.6030804@bbs.darktech.org> <4E1DD737.9010800@oracle.com> <4E1DE398.1060302@bbs.darktech.org> <4E1DE86B.6030501@oracle.com> Message-ID: <1310588146699-6580550.post@n2.nabble.com> Alan Bateman-2 wrote: > > cowwoc wrote: >> >> I don't see why the <= 0 case is less clear. The way I see it, >> read() is an asynchronous layer on top of a synchronous readImpl() >> API. If we're saying that timeout <= 0 means "return immediately" then >> surely readImpl(timeout<=0) should return right away. read() isn't >> part of the equation because (as we both agree) the timeouts are >> really parameters for readImpl(), not read(). > It's not generally a layer over a synchronous API in blocking mode as > that would be problematic when there are tens of thousands of > connections. The timeout is also not generally something that the > underlying implementation knows about either. It could do in some > implementations but it is more likely to be an add-on with the > underlying implementation making use of the operating system's > asynchronous I/O support or maybe be based on non-blocking I/O. > I feel as though we're nitpicking implementation details here. As an end-user I picture an asynchronous read as an *abstraction* of invoking a synchronous read in a separate thread. As an end-user I don't know or care about the low-level details. I fully appreciate the fact that this isn't actually the way the underlying implementation works because I've actually implemented my own channel on top of Completion Ports, similar to the way you have in AsynchronousSocketChannelImpl. There is no technical reason you couldn't implement timeout <= 0 to mean "return immediately with available bytes". I know, because I've done this for my own channel. I've provided you with many concrete reasons why treating timeout <= 0 as "return immediately" is the right way to go and why adding separate methods later on will cause problems. The only reason we started with timeout <= 0 as "wait forever" was a precedence set by C-language; but we're using Java here and java.util.concurrent should be *our* precedence. Is it possible to get a third person into the conversation? I think I third pair of eyes will help us resolve this dispute. PS: You don't need to actually *implement* timeout <= 0 as returning available bytes. All you need to do is put it in the specification and return 0 for now (as if there are no available bytes). We can improve the implementation later on. I'm mostly worried about the specification here. Gili -- View this message in context: http://nio-dev.3157472.n2.nabble.com/AsynchronousSocketChannel-still-throws-unspecified-exception-tp6471557p6580550.html Sent from the nio-dev mailing list archive at Nabble.com. From Alan.Bateman at oracle.com Wed Jul 13 14:06:38 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Jul 2011 22:06:38 +0100 Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <1310588146699-6580550.post@n2.nabble.com> References: <1309811091219-6547293.post@n2.nabble.com> <4E1D5D7E.1050001@oracle.com> <1310559500455-6578786.post@n2.nabble.com> <4E1DA037.7060202@oracle.com> <1310569458197-6579342.post@n2.nabble.com> <4E1DBF09.30208@oracle.com> <4E1DCAC7.6030804@bbs.darktech.org> <4E1DD737.9010800@oracle.com> <4E1DE398.1060302@bbs.darktech.org> <4E1DE86B.6030501@oracle.com> <1310588146699-6580550.post@n2.nabble.com> Message-ID: <4E1E08DE.2080900@oracle.com> cowwoc wrote: > : > I've provided you > with many concrete reasons why treating timeout <= 0 as "return immediately" > is the right way to go Yes, and this is useful as it's attempting to use the API in a different way that it was envisaged. > : > > PS: You don't need to actually *implement* timeout <= 0 as returning > available bytes. All you need to do is put it in the specification and > return 0 for now (as if there are no available bytes). We can improve the > implementation later on. I'm mostly worried about the specification here. > We can't change this for jdk7 but we what we can do is decide the right solution for jdk8. -Alan. From cowwoc at bbs.darktech.org Sat Jul 16 08:33:31 2011 From: cowwoc at bbs.darktech.org (cowwoc) Date: Sat, 16 Jul 2011 08:33:31 -0700 (PDT) Subject: AsynchronousSocketChannel still throws unspecified exception In-Reply-To: <4E1E08DE.2080900@oracle.com> References: <1310559500455-6578786.post@n2.nabble.com> <4E1DA037.7060202@oracle.com> <1310569458197-6579342.post@n2.nabble.com> <4E1DBF09.30208@oracle.com> <4E1DCAC7.6030804@bbs.darktech.org> <4E1DD737.9010800@oracle.com> <4E1DE398.1060302@bbs.darktech.org> <4E1DE86B.6030501@oracle.com> <1310588146699-6580550.post@n2.nabble.com> <4E1E08DE.2080900@oracle.com> Message-ID: <4E21AF06.9030707@bbs.darktech.org> Fair enough. I understand that we're too far along the JDK7 release schedule. Thanks, Gili On 13/07/2011 5:08 PM, Alan Bateman-2 [via nio-dev] wrote: > cowwoc wrote: > > : > > I've provided you > > with many concrete reasons why treating timeout <= 0 as "return > immediately" > > is the right way to go > Yes, and this is useful as it's attempting to use the API in a different > way that it was envisaged. > > > : > > > > PS: You don't need to actually *implement* timeout <= 0 as returning > > available bytes. All you need to do is put it in the specification and > > return 0 for now (as if there are no available bytes). We can > improve the > > implementation later on. I'm mostly worried about the specification > here. > > > We can't change this for jdk7 but we what we can do is decide the right > solution for jdk8. > > -Alan. > > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the > discussion below: > http://nio-dev.3157472.n2.nabble.com/AsynchronousSocketChannel-still-throws-unspecified-exception-tp6471557p6580775.html > > To unsubscribe from AsynchronousSocketChannel still throws unspecified > exception, click here > . > -- View this message in context: http://nio-dev.3157472.n2.nabble.com/AsynchronousSocketChannel-still-throws-unspecified-exception-tp6471557p6589792.html Sent from the nio-dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110716/56c4e4da/attachment.html From spoole at linux.vnet.ibm.com Mon Jul 18 14:54:35 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Mon, 18 Jul 2011 22:54:35 +0100 Subject: java.nio.BufferPoolMXBean getObjectName() occasionally returns null Message-ID: <4E24AB9B.1030209@linux.vnet.ibm.com> Hi all, a small fix to a race condition that occurs under extreme and probably unrepresentative loading... sun.management.ManagementFactoryHelper provides the default implementation of java.nio.BufferPoolMXBean. The getObjectName() method uses a volatile field to store the object name. The name is filled in using a lazy sync method. Under high load a timing window is exposed in which the lazy sync succeeds but a caller still recieves null. The failing code is question is in src/share/classes/sun/management/ManagementFactoryHelper.java The diff and testcase are attached. I don't know if the testcase is the right form - it creates a bunch of threads that drive the method to expose the problem and is fairly quick. I can show it happening on Ubuntu with JDK7 and with my local build of JDK8. Cheers Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: BufferPoolMXBeanObjectNameStressTest.java Type: text/x-java Size: 2608 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110718/edb184e9/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: jmx.diff Type: text/x-patch Size: 654 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110718/edb184e9/attachment-0001.bin From Alan.Bateman at oracle.com Mon Jul 18 21:09:37 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Jul 2011 05:09:37 +0100 Subject: java.nio.BufferPoolMXBean getObjectName() occasionally returns null Message-ID: <4E250380.1000409@oracle.com> (cc'ing serviceability-dev) Thanks Steve, looks like this crept as part of some refactoring work [1]. Looks like PlatformLoggingMXBean has the same issue. I've created the following bug to track it: 7068328: BufferPoolMXBean and PlatformLoggingMXBean getObjectName may return null If no one take it in the next few days then I can take it and get it push to jdk8 (listing you are contributer). The test will need a bit of clean-up, re-formatting, and throwing an exception rather than calling System.exit for example. -Alan [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/77dd50ba670b -------- Original Message -------- Subject: java.nio.BufferPoolMXBean getObjectName() occasionally returns null Date: Mon, 18 Jul 2011 22:54:35 +0100 From: Steve Poole To: nio-dev at openjdk.java.net Hi all, a small fix to a race condition that occurs under extreme and probably unrepresentative loading... sun.management.ManagementFactoryHelper provides the default implementation of java.nio.BufferPoolMXBean. The getObjectName() method uses a volatile field to store the object name. The name is filled in using a lazy sync method. Under high load a timing window is exposed in which the lazy sync succeeds but a caller still recieves null. The failing code is question is in src/share/classes/sun/management/ManagementFactoryHelper.java The diff and testcase are attached. I don't know if the testcase is the right form - it creates a bunch of threads that drive the method to expose the problem and is fairly quick. I can show it happening on Ubuntu with JDK7 and with my local build of JDK8. Cheers Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110719/2526162f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: BufferPoolMXBeanObjectNameStressTest.java Type: text/x-java Size: 2609 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110719/2526162f/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: jmx.diff Type: text/x-patch Size: 655 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110719/2526162f/attachment-0001.bin From spoole at linux.vnet.ibm.com Mon Jul 18 22:51:27 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Tue, 19 Jul 2011 06:51:27 +0100 Subject: java.nio.BufferPoolMXBean getObjectName() occasionally returns null In-Reply-To: <4E250380.1000409@oracle.com> References: <4E250380.1000409@oracle.com> Message-ID: <4E251B5F.2020306@linux.vnet.ibm.com> On 19/07/11 05:09, Alan Bateman wrote: > (cc'ing serviceability-dev) > > Thanks Steve, looks like this crept as part of some refactoring work > [1]. Looks like PlatformLoggingMXBean has the same issue. I've created > the following bug to track it: > > 7068328: BufferPoolMXBean and PlatformLoggingMXBean getObjectName may > return null > > If no one take it in the next few days then I can take it and get it > push to jdk8 (listing you are contributer). The test will need a bit > of clean-up, re-formatting, and throwing an exception rather than > calling System.exit for example. > Thanks Alan. I wasn't sure of the testcase form to use for a multithreaded problem - I will be curious to see how it ends up. > -Alan > > [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/77dd50ba670b > > > > -------- Original Message -------- > Subject: java.nio.BufferPoolMXBean getObjectName() occasionally > returns null > Date: Mon, 18 Jul 2011 22:54:35 +0100 > From: Steve Poole > To: nio-dev at openjdk.java.net > > > > Hi all, a small fix to a race condition that occurs under extreme and > probably unrepresentative loading... > > sun.management.ManagementFactoryHelper provides the default > implementation of java.nio.BufferPoolMXBean. The getObjectName() method > uses a volatile field to store the object name. The name is filled in > using a lazy sync method. Under high load a timing window is exposed in > which the lazy sync succeeds but a caller still recieves null. > > The failing code is question is in > src/share/classes/sun/management/ManagementFactoryHelper.java > > The diff and testcase are attached. > > I don't know if the testcase is the right form - it creates a bunch of > threads that drive the method to expose the problem and is fairly > quick. I can show it happening on Ubuntu with JDK7 and with my local > build of JDK8. > > Cheers > > Steve > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110719/ce3eb9a9/attachment.html From cowwoc at bbs.darktech.org Tue Jul 19 05:57:52 2011 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 Jul 2011 05:57:52 -0700 (PDT) Subject: Question about AsynchronousByteChannel.read() In-Reply-To: <4E1D57DD.6030104@oracle.com> References: <1310391750347-6570959.post@n2.nabble.com> <4E1D57DD.6030104@oracle.com> Message-ID: <1311080272123-6598698.post@n2.nabble.com> Alan Bateman-2 wrote: > > Yes, it depends on the channel type. With a channel to a stream oriented > connection then it doesn't always make sense to have more than one > outstanding I/O operations of a given type as they would complete in an > undefined order (and with an operation such as write then it would > easily "corrupt" the stream for example). However it does make sense for > other channel types, for example AsynchronousFileChannel where there may > be I/O operations to different parts of the file happening at the same > thing. If you go back through the archives of this list then you should > find some prior discussion on queuing of I/O operations that make be > useful to you. > Couldn't steam-oriented channels simply queue incoming requests and handle them on a first-come first-serve basis? Gili -- View this message in context: http://nio-dev.3157472.n2.nabble.com/Question-about-AsynchronousByteChannel-read-tp6570959p6598698.html Sent from the nio-dev mailing list archive at Nabble.com. From Alan.Bateman at oracle.com Tue Jul 19 06:30:52 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Jul 2011 14:30:52 +0100 Subject: java.nio.BufferPoolMXBean getObjectName() occasionally returns null In-Reply-To: <4E251B5F.2020306@linux.vnet.ibm.com> References: <4E250380.1000409@oracle.com> <4E251B5F.2020306@linux.vnet.ibm.com> Message-ID: <4E25870C.8090903@oracle.com> Steve Poole wrote: > On 19/07/11 05:09, Alan Bateman wrote: >> (cc'ing serviceability-dev) >> >> Thanks Steve, looks like this crept as part of some refactoring work >> [1]. Looks like PlatformLoggingMXBean has the same issue. I've >> created the following bug to track it: >> >> 7068328: BufferPoolMXBean and PlatformLoggingMXBean getObjectName may >> return null >> >> If no one take it in the next few days then I can take it and get it >> push to jdk8 (listing you are contributer). The test will need a bit >> of clean-up, re-formatting, and throwing an exception rather than >> calling System.exit for example. >> > Thanks Alan. I wasn't sure of the testcase form to use for a > multithreaded problem - I will be curious to see how it ends up. The approach to have a pool of threads bang on the list returned by ManagementFactory.getPlatformMXBeans(BufferPoolMXBean.class) seems reasonable (I can't think of other ways that would easily demonstrate this bug). The main thing with tests such as this is they are highly robust and run quickly. If you have cycles to improve the test then the main comment is that jtreg tests can't call System.exit (a shell test that runs the class could but we try to avoid shell tests for several reasons). One suggestion is to just add a static volatile boolean failed and set it to true if the object name is null or doesn't start with "java.nio:type=BufferPool,name=" (that would be more comprehensive that checking for the empty string). At the end of the test then throw a RuntimeException if failed is true. I would also suggest using the Executors factory class rather than creating the ThreadPoolExecutor explicitly. You could invoke the shutdown method before awaitTermination. Another thing is that 1 second is likely to be insufficient when run on a busy machine. That isn't a correctness issue but subsequent j.l.management tests that run in the same VM might observe thread counts that they don't expect. The final comment is just the indenting. We use 4 space indent but the attachment seem to be 8 (Windows tabs perhaps?). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110719/bf128061/attachment-0001.html From Alan.Bateman at oracle.com Tue Jul 19 06:38:51 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Jul 2011 14:38:51 +0100 Subject: Question about AsynchronousByteChannel.read() In-Reply-To: <1311080272123-6598698.post@n2.nabble.com> References: <1310391750347-6570959.post@n2.nabble.com> <4E1D57DD.6030104@oracle.com> <1311080272123-6598698.post@n2.nabble.com> Message-ID: <4E2588EB.4060702@oracle.com> cowwoc wrote: > : > Couldn't steam-oriented channels simply queue incoming requests and handle > them on a first-come first-serve basis? > That would mean the completion handlers could run concurrently or even out of order and would be tricky to handle. With writing then it could lead to corruption of the stream (esp. if multiple threads attemped to initiate write operations to the stream at around the same time). For now AsynchronousSocketChannel doesn't have any support for queuing of I/O operations. It may be something we have to come back to in the future. There is some prior discussion on this list about this topic that may be useful. -Alan From cowwoc at bbs.darktech.org Tue Jul 19 06:42:31 2011 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 Jul 2011 09:42:31 -0400 Subject: Question about AsynchronousByteChannel.read() In-Reply-To: <4E2588EB.4060702@oracle.com> References: <1310391750347-6570959.post@n2.nabble.com> <4E1D57DD.6030104@oracle.com> <1311080272123-6598698.post@n2.nabble.com> <4E2588EB.4060702@oracle.com> Message-ID: <4E2589C7.8090306@bbs.darktech.org> On 19/07/2011 9:38 AM, Alan Bateman wrote: > cowwoc wrote: >> : >> Couldn't steam-oriented channels simply queue incoming requests and >> handle >> them on a first-come first-serve basis? > That would mean the completion handlers could run concurrently or even > out of order and would be tricky to handle. ... How so? If we queue incoming requests, only one operation runs at a time. Completion handlers are guaranteed to return in the order in which they were submitted. Am I missing something? Gili From Alan.Bateman at oracle.com Tue Jul 19 07:44:26 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Jul 2011 15:44:26 +0100 Subject: Question about AsynchronousByteChannel.read() In-Reply-To: <4E2589C7.8090306@bbs.darktech.org> References: <1310391750347-6570959.post@n2.nabble.com> <4E1D57DD.6030104@oracle.com> <1311080272123-6598698.post@n2.nabble.com> <4E2588EB.4060702@oracle.com> <4E2589C7.8090306@bbs.darktech.org> Message-ID: <4E25984A.8080001@oracle.com> cowwoc wrote: > > ... How so? If we queue incoming requests, only one operation runs > at a time. Completion handlers are guaranteed to return in the order > in which they were submitted. Am I missing something? If by "return" you mean execute then there isn't any guarantee. Even today if you initiate two read operations in quick succession, and if you specify two different completion handlers that just print a trace message, then it's possible that they the trace messages will not be printed in the order that you expect. -Alan. From cowwoc at bbs.darktech.org Tue Jul 19 08:33:42 2011 From: cowwoc at bbs.darktech.org (cowwoc) Date: Tue, 19 Jul 2011 08:33:42 -0700 (PDT) Subject: Question about AsynchronousByteChannel.read() In-Reply-To: <4E25984A.8080001@oracle.com> References: <1310391750347-6570959.post@n2.nabble.com> <4E1D57DD.6030104@oracle.com> <1311080272123-6598698.post@n2.nabble.com> <4E2588EB.4060702@oracle.com> <4E2589C7.8090306@bbs.darktech.org> <4E25984A.8080001@oracle.com> Message-ID: <4E25A3C3.9090103@bbs.darktech.org> On 19/07/2011 10:45 AM, Alan Bateman-2 [via nio-dev] wrote: > cowwoc wrote: > > > > ... How so? If we queue incoming requests, only one operation runs > > at a time. Completion handlers are guaranteed to return in the order > > in which they were submitted. Am I missing something? > If by "return" you mean execute then there isn't any guarantee. Even > today if you initiate two read operations in quick succession, and if > you specify two different completion handlers that just print a trace > message, then it's possible that they the trace messages will not be > printed in the order that you expect. > > -Alan. > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the > discussion below: > http://nio-dev.3157472.n2.nabble.com/Question-about-AsynchronousByteChannel-read-tp6570959p6599032.html > > To unsubscribe from Question about AsynchronousByteChannel.read(), > click here > . > Don't I get to make that guarantee as the Channel implementer? I can use a single consumer thread for reads, thereby guaranteeing that requests will be honored in the order they are submitted. Gili -- View this message in context: http://nio-dev.3157472.n2.nabble.com/Question-about-AsynchronousByteChannel-read-tp6570959p6599194.html Sent from the nio-dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110719/dae71158/attachment.html From spoole at linux.vnet.ibm.com Thu Jul 21 11:43:24 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Thu, 21 Jul 2011 19:43:24 +0100 Subject: java.nio.BufferPoolMXBean getObjectName() occasionally returns null In-Reply-To: <4E25870C.8090903@oracle.com> References: <4E250380.1000409@oracle.com> <4E251B5F.2020306@linux.vnet.ibm.com> <4E25870C.8090903@oracle.com> Message-ID: <4E28734C.7020604@linux.vnet.ibm.com> On 19/07/11 14:30, Alan Bateman wrote: > Steve Poole wrote: >> On 19/07/11 05:09, Alan Bateman wrote: >>> (cc'ing serviceability-dev) >>> >>> Thanks Steve, looks like this crept as part of some refactoring work >>> [1]. Looks like PlatformLoggingMXBean has the same issue. I've >>> created the following bug to track it: >>> >>> 7068328: BufferPoolMXBean and PlatformLoggingMXBean getObjectName >>> may return null >>> >>> If no one take it in the next few days then I can take it and get it >>> push to jdk8 (listing you are contributer). The test will need a bit >>> of clean-up, re-formatting, and throwing an exception rather than >>> calling System.exit for example. >>> >> Thanks Alan. I wasn't sure of the testcase form to use for a >> multithreaded problem - I will be curious to see how it ends up. > The approach to have a pool of threads bang on the list returned by > ManagementFactory.getPlatformMXBeans(BufferPoolMXBean.class) seems > reasonable (I can't think of other ways that would easily demonstrate > this bug). The main thing with tests such as this is they are highly > robust and run quickly. > > If you have cycles to improve the test then the main comment is that > jtreg tests can't call System.exit (a shell test that runs the class > could but we try to avoid shell tests for several reasons). One > suggestion is to just add a static volatile boolean failed and set it > to true if the object name is null or doesn't start with > "java.nio:type=BufferPool,name=" (that would be more comprehensive > that checking for the empty string). At the end of the test then throw > a RuntimeException if failed is true. I do have cycles but not for a week or so - I've been preping for two trips back to back starting tomorrow - I'll keep this mail around to remind me. > > I would also suggest using the Executors factory class rather than > creating the ThreadPoolExecutor explicitly. You could invoke the > shutdown method before awaitTermination. Another thing is that 1 > second is likely to be insufficient when run on a busy machine. That > isn't a correctness issue but subsequent j.l.management tests that run > in the same VM might observe thread counts that they don't expect. > > The final comment is just the indenting. We use 4 space indent but the > attachment seem to be 8 (Windows tabs perhaps?). Actually its eclipse on Ubuntu - I will have to fix it: the tabbing, not using Ubuntu or eclipse :-) > > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110721/8fda13ba/attachment.html From alexandre.boulgakov at oracle.com Wed Jul 27 14:42:08 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Wed, 27 Jul 2011 14:42:08 -0700 Subject: Code review request: 7068616 NIO libraries do not build with javac -Xlint:all,-deprecation -Werror Message-ID: <4E308630.8040304@oracle.com> Hello everyone, Please review these NIO changes. Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068616 webrev: http://cr.openjdk.java.net/~alanb/7068616/webrev/ Most of the changes are one-line fixes to remove warnings, and I've updated the make files to flag warnings as errors from now on, ignoring deprecation warnings in sun.io.*. I also revised some of the try-catch blocks to make use of multicatch syntax. There are two larger changes in src/solaris/classes/sun/nio/ch/SctpChannelImpl.java and src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java, where I changed a private inner class from "private class InternalNotificationHandler extends AbstractNotificationHandler" to "private class InternalNotificationHandler extends AbstractNotificationHandler" because it was not using the type variable T. AbstractNotificationHandler is consistent with the original behavior where InternalNotificationHandler was used as a raw type. Thanks, Sasha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110727/3f0c1341/attachment.html From chris.hegarty at oracle.com Thu Jul 28 02:27:40 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 28 Jul 2011 10:27:40 +0100 Subject: Code review request: 7068616 NIO libraries do not build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E308630.8040304@oracle.com> References: <4E308630.8040304@oracle.com> Message-ID: <4E312B8C.5060105@oracle.com> Hi Sasha, Thanks for cleaning up these warnings. I reviewed all the changes, paying particular attention to SCTP, and I'm happy with them. One minor comment, for Charset.java Since providers() now returns a Iterator, the callers of this method could also be updated to use the generified type and remove (what would be) a redundant cast. Thanks, -Chris. On 07/27/11 10:42 PM, Alexandre Boulgakov wrote: > Hello everyone, > > Please review these NIO changes. > Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068616 > > webrev: http://cr.openjdk.java.net/~alanb/7068616/webrev/ > > Most of the changes are one-line fixes to remove warnings, and I've > updated the make files to flag warnings as errors from now on, ignoring > deprecation warnings in sun.io.*. I also revised some of the try-catch > blocks to make use of multicatch syntax. > > There are two larger changes in > src/solaris/classes/sun/nio/ch/SctpChannelImpl.java and > src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java, where I > changed a private inner class from "private class > InternalNotificationHandler extends AbstractNotificationHandler" > to "private class InternalNotificationHandler extends > AbstractNotificationHandler" because it was not using the type > variable T. AbstractNotificationHandler is consistent with the > original behavior where InternalNotificationHandler was used as a raw type. > > Thanks, > Sasha From Alan.Bateman at oracle.com Thu Jul 28 08:18:58 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Jul 2011 16:18:58 +0100 Subject: Code review request: 7068616 NIO libraries do not build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E308630.8040304@oracle.com> References: <4E308630.8040304@oracle.com> Message-ID: <4E317DE2.8030701@oracle.com> Alexandre Boulgakov wrote: > Hello everyone, > > Please review these NIO changes. > Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068616 > > webrev: http://cr.openjdk.java.net/~alanb/7068616/webrev/ > > Most of the changes are one-line fixes to remove warnings, and I've > updated the make files to flag warnings as errors from now on, > ignoring deprecation warnings in sun.io.*. I also revised some of the > try-catch blocks to make use of multicatch syntax. > > There are two larger changes in > src/solaris/classes/sun/nio/ch/SctpChannelImpl.java and > src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java, where I > changed a private inner class from "private class > InternalNotificationHandler extends AbstractNotificationHandler" > to "private class InternalNotificationHandler extends > AbstractNotificationHandler" because it was not using the type > variable T. AbstractNotificationHandler is consistent with the > original behavior where InternalNotificationHandler was used as a raw > type. > > Thanks, > Sasha Thanks for doing this. It's okay to ignore sun.io as that be likely be removed from jdk8 soon (the legacy sun.io converters have been death row for many releases). The changes seem okay to me. Minor nit in sun/nio/ch/Reflect.java is that the parameters to lookupConstructor are no longer aligned. Also I assume you've verified that it builds on all platforms as this area has platform specific classes. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110728/7cff0caf/attachment.html From alexandre.boulgakov at oracle.com Thu Jul 28 11:12:29 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Thu, 28 Jul 2011 11:12:29 -0700 Subject: Code review request: 7068616 NIO libraries do not build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E312B8C.5060105@oracle.com> References: <4E308630.8040304@oracle.com> <4E312B8C.5060105@oracle.com> Message-ID: <4E31A68D.40500@oracle.com> It seems strange that javac didn't emit a "raw types" warning on the raw Iterator. Do you know if that is by design, or is it a bug? -Sasha On 7/28/2011 2:27 AM, Chris Hegarty wrote: > Hi Sasha, > > Thanks for cleaning up these warnings. > > I reviewed all the changes, paying particular attention to SCTP, and > I'm happy with them. > > One minor comment, for Charset.java > > Since providers() now returns a Iterator, > the callers of this method could also be updated to use the > generified type and remove (what would be) a redundant cast. > > Thanks, > -Chris. > > On 07/27/11 10:42 PM, Alexandre Boulgakov wrote: >> Hello everyone, >> >> Please review these NIO changes. >> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068616 >> >> webrev: http://cr.openjdk.java.net/~alanb/7068616/webrev/ >> >> Most of the changes are one-line fixes to remove warnings, and I've >> updated the make files to flag warnings as errors from now on, ignoring >> deprecation warnings in sun.io.*. I also revised some of the try-catch >> blocks to make use of multicatch syntax. >> >> There are two larger changes in >> src/solaris/classes/sun/nio/ch/SctpChannelImpl.java and >> src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java, where I >> changed a private inner class from "private class >> InternalNotificationHandler extends AbstractNotificationHandler" >> to "private class InternalNotificationHandler extends >> AbstractNotificationHandler" because it was not using the type >> variable T. AbstractNotificationHandler is consistent with the >> original behavior where InternalNotificationHandler was used as a raw >> type. >> >> Thanks, >> Sasha From alexandre.boulgakov at oracle.com Thu Jul 28 11:12:36 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Thu, 28 Jul 2011 11:12:36 -0700 Subject: Code review request: 7068616 NIO libraries do not build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E317DE2.8030701@oracle.com> References: <4E308630.8040304@oracle.com> <4E317DE2.8030701@oracle.com> Message-ID: <4E31A694.2070801@oracle.com> On 7/28/2011 8:18 AM, Alan Bateman wrote: > Alexandre Boulgakov wrote: >> Hello everyone, >> >> Please review these NIO changes. >> Bug detail: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068616 >> >> webrev: http://cr.openjdk.java.net/~alanb/7068616/webrev/ >> >> Most of the changes are one-line fixes to remove warnings, and I've >> updated the make files to flag warnings as errors from now on, >> ignoring deprecation warnings in sun.io.*. I also revised some of the >> try-catch blocks to make use of multicatch syntax. >> >> There are two larger changes in >> src/solaris/classes/sun/nio/ch/SctpChannelImpl.java and >> src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java, where I >> changed a private inner class from "private class >> InternalNotificationHandler extends >> AbstractNotificationHandler" to "private class >> InternalNotificationHandler extends >> AbstractNotificationHandler" because it was not using the >> type variable T. AbstractNotificationHandler is consistent >> with the original behavior where InternalNotificationHandler was used >> as a raw type. >> >> Thanks, >> Sasha > Thanks for doing this. It's okay to ignore sun.io as that be likely be > removed from jdk8 soon (the legacy sun.io converters have been death > row for many releases). > > The changes seem okay to me. Minor nit in sun/nio/ch/Reflect.java is > that the parameters to lookupConstructor are no longer aligned. Also I > assume you've verified that it builds on all platforms as this area > has platform specific classes. Yes, I've built it on all platforms. I've fixed the alignment, but I don't think that merits another webrev. Cheers, Sasha > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110728/461f25e4/attachment.html From alexandre.boulgakov at oracle.com Thu Jul 28 11:16:07 2011 From: alexandre.boulgakov at oracle.com (Alexandre Boulgakov) Date: Thu, 28 Jul 2011 11:16:07 -0700 Subject: Code review request: 7068616 NIO libraries do not build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E312B8C.5060105@oracle.com> References: <4E308630.8040304@oracle.com> <4E312B8C.5060105@oracle.com> Message-ID: <4E31A767.9020602@oracle.com> Here's the new patch for Charset.java. (The last two chunks are new, everything else is the same.) -Sasha On 7/28/2011 2:27 AM, Chris Hegarty wrote: > Hi Sasha, > > Thanks for cleaning up these warnings. > > I reviewed all the changes, paying particular attention to SCTP, and > I'm happy with them. > > One minor comment, for Charset.java > > Since providers() now returns a Iterator, > the callers of this method could also be updated to use the > generified type and remove (what would be) a redundant cast. > > Thanks, > -Chris. > > On 07/27/11 10:42 PM, Alexandre Boulgakov wrote: >> Hello everyone, >> >> Please review these NIO changes. >> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068616 >> >> webrev: http://cr.openjdk.java.net/~alanb/7068616/webrev/ >> >> Most of the changes are one-line fixes to remove warnings, and I've >> updated the make files to flag warnings as errors from now on, ignoring >> deprecation warnings in sun.io.*. I also revised some of the try-catch >> blocks to make use of multicatch syntax. >> >> There are two larger changes in >> src/solaris/classes/sun/nio/ch/SctpChannelImpl.java and >> src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java, where I >> changed a private inner class from "private class >> InternalNotificationHandler extends AbstractNotificationHandler" >> to "private class InternalNotificationHandler extends >> AbstractNotificationHandler" because it was not using the type >> variable T. AbstractNotificationHandler is consistent with the >> original behavior where InternalNotificationHandler was used as a raw >> type. >> >> Thanks, >> Sasha -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Charset.patch Url: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110728/4c083044/attachment-0001.ksh From chris.hegarty at oracle.com Thu Jul 28 13:24:05 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 28 Jul 2011 21:24:05 +0100 Subject: Code review request: 7068616 NIO libraries do not build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E31A767.9020602@oracle.com> References: <4E308630.8040304@oracle.com> <4E312B8C.5060105@oracle.com> <4E31A767.9020602@oracle.com> Message-ID: <4E31C565.6020100@oracle.com> Thanks Sasha, looks good to me. -Chris. On 07/28/11 07:16 PM, Alexandre Boulgakov wrote: > Here's the new patch for Charset.java. (The last two chunks are new, > everything else is the same.) > > -Sasha > > On 7/28/2011 2:27 AM, Chris Hegarty wrote: >> Hi Sasha, >> >> Thanks for cleaning up these warnings. >> >> I reviewed all the changes, paying particular attention to SCTP, and >> I'm happy with them. >> >> One minor comment, for Charset.java >> >> Since providers() now returns a Iterator, >> the callers of this method could also be updated to use the >> generified type and remove (what would be) a redundant cast. >> >> Thanks, >> -Chris. >> >> On 07/27/11 10:42 PM, Alexandre Boulgakov wrote: >>> Hello everyone, >>> >>> Please review these NIO changes. >>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068616 >>> >>> webrev: http://cr.openjdk.java.net/~alanb/7068616/webrev/ >>> >>> Most of the changes are one-line fixes to remove warnings, and I've >>> updated the make files to flag warnings as errors from now on, ignoring >>> deprecation warnings in sun.io.*. I also revised some of the try-catch >>> blocks to make use of multicatch syntax. >>> >>> There are two larger changes in >>> src/solaris/classes/sun/nio/ch/SctpChannelImpl.java and >>> src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java, where I >>> changed a private inner class from "private class >>> InternalNotificationHandler extends AbstractNotificationHandler" >>> to "private class InternalNotificationHandler extends >>> AbstractNotificationHandler" because it was not using the type >>> variable T. AbstractNotificationHandler is consistent with the >>> original behavior where InternalNotificationHandler was used as a raw >>> type. >>> >>> Thanks, >>> Sasha From chris.hegarty at oracle.com Thu Jul 28 13:27:44 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 28 Jul 2011 21:27:44 +0100 Subject: Code review request: 7068616 NIO libraries do not build with javac -Xlint:all,-deprecation -Werror In-Reply-To: <4E31A68D.40500@oracle.com> References: <4E308630.8040304@oracle.com> <4E312B8C.5060105@oracle.com> <4E31A68D.40500@oracle.com> Message-ID: <4E31C640.50605@oracle.com> On 07/28/11 07:12 PM, Alexandre Boulgakov wrote: > It seems strange that javac didn't emit a "raw types" warning on the raw > Iterator. Do you know if that is by design, or is it a bug? I'm not sure why javac didn't generate a warning for this. I only noticed it because providers is private and I wondered where it was being called. It may be worth trying to create a simple testcase that demonstrates this and send it to compiler-dev, but it shouldn't prevent this work from progressing. -Chris. > -Sasha > > On 7/28/2011 2:27 AM, Chris Hegarty wrote: >> Hi Sasha, >> >> Thanks for cleaning up these warnings. >> >> I reviewed all the changes, paying particular attention to SCTP, and >> I'm happy with them. >> >> One minor comment, for Charset.java >> >> Since providers() now returns a Iterator, >> the callers of this method could also be updated to use the >> generified type and remove (what would be) a redundant cast. >> >> Thanks, >> -Chris. >> >> On 07/27/11 10:42 PM, Alexandre Boulgakov wrote: >>> Hello everyone, >>> >>> Please review these NIO changes. >>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068616 >>> >>> webrev: http://cr.openjdk.java.net/~alanb/7068616/webrev/ >>> >>> Most of the changes are one-line fixes to remove warnings, and I've >>> updated the make files to flag warnings as errors from now on, ignoring >>> deprecation warnings in sun.io.*. I also revised some of the try-catch >>> blocks to make use of multicatch syntax. >>> >>> There are two larger changes in >>> src/solaris/classes/sun/nio/ch/SctpChannelImpl.java and >>> src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java, where I >>> changed a private inner class from "private class >>> InternalNotificationHandler extends AbstractNotificationHandler" >>> to "private class InternalNotificationHandler extends >>> AbstractNotificationHandler" because it was not using the type >>> variable T. AbstractNotificationHandler is consistent with the >>> original behavior where InternalNotificationHandler was used as a raw >>> type. >>> >>> Thanks, >>> Sasha From mike.duigou at oracle.com Thu Jul 28 15:20:27 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 28 Jul 2011 15:20:27 -0700 Subject: Code review request: 7068616 NIO libraries do not build with javac -Xlint:all, -deprecation -Werror In-Reply-To: <4E31A767.9020602@oracle.com> References: <4E308630.8040304@oracle.com> <4E312B8C.5060105@oracle.com> <4E31A767.9020602@oracle.com> Message-ID: <8329F6EB-78CC-49B2-973A-54F1D3FC0DA8@oracle.com> I didn't review the other files but this Charset patch looks fine. On Jul 28 2011, at 11:16 , Alexandre Boulgakov wrote: > Here's the new patch for Charset.java. (The last two chunks are new, everything else is the same.) > > -Sasha > > On 7/28/2011 2:27 AM, Chris Hegarty wrote: >> Hi Sasha, >> >> Thanks for cleaning up these warnings. >> >> I reviewed all the changes, paying particular attention to SCTP, and I'm happy with them. >> >> One minor comment, for Charset.java >> >> Since providers() now returns a Iterator, >> the callers of this method could also be updated to use the >> generified type and remove (what would be) a redundant cast. >> >> Thanks, >> -Chris. >> >> On 07/27/11 10:42 PM, Alexandre Boulgakov wrote: >>> Hello everyone, >>> >>> Please review these NIO changes. >>> Bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7068616 >>> >>> webrev: http://cr.openjdk.java.net/~alanb/7068616/webrev/ >>> >>> Most of the changes are one-line fixes to remove warnings, and I've >>> updated the make files to flag warnings as errors from now on, ignoring >>> deprecation warnings in sun.io.*. I also revised some of the try-catch >>> blocks to make use of multicatch syntax. >>> >>> There are two larger changes in >>> src/solaris/classes/sun/nio/ch/SctpChannelImpl.java and >>> src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java, where I >>> changed a private inner class from "private class >>> InternalNotificationHandler extends AbstractNotificationHandler" >>> to "private class InternalNotificationHandler extends >>> AbstractNotificationHandler" because it was not using the type >>> variable T. AbstractNotificationHandler is consistent with the >>> original behavior where InternalNotificationHandler was used as a raw type. >>> >>> Thanks, >>> Sasha >