From Alan.Bateman at oracle.com Mon Nov 1 07:22:45 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 01 Nov 2010 14:22:45 +0000 Subject: anyone using AsynchronousDatagramChannel? In-Reply-To: <4CC08DBB.9000904@oracle.com> References: <4CC08DBB.9000904@oracle.com> Message-ID: <4CCECD35.7020004@oracle.com> Just to follow up on this one, the webrev with the changes is here: http://cr.openjdk.java.net/~alanb/6993126/webrev/ -Alan. From Alan.Bateman at oracle.com Mon Nov 1 08:57:00 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 01 Nov 2010 15:57:00 +0000 Subject: 6431343: (dc) DatagramChannel may not report its local address correctly after connect or disconnect Message-ID: <4CCEE34C.6050301@oracle.com> If a DatagramChannel is bound to the wildcard address then the connect can cause the local address is "change" to a specific address. Similarly a disconnect can cause it to revert to the wildcard address. This patch fixes the getLocalAddress method so that it returns the actual local address, bringing it in line with legacy DatagramSocket. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/6431343/webrev/ Thanks, Alan From chris.hegarty at oracle.com Mon Nov 1 13:52:02 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 01 Nov 2010 20:52:02 +0000 Subject: 6431343: (dc) DatagramChannel may not report its local address correctly after connect or disconnect In-Reply-To: <4CCEE34C.6050301@oracle.com> References: <4CCEE34C.6050301@oracle.com> Message-ID: <4CCF2872.7050101@oracle.com> The changes look fine to me. -Chris. Alan Bateman wrote: > > If a DatagramChannel is bound to the wildcard address then the connect > can cause the local address is "change" to a specific address. Similarly > a disconnect can cause it to revert to the wildcard address. This patch > fixes the getLocalAddress method so that it returns the actual local > address, bringing it in line with legacy DatagramSocket. The webrev with > the changes is here: > http://cr.openjdk.java.net/~alanb/6431343/webrev/ > > Thanks, > Alan From chris.hegarty at oracle.com Tue Nov 2 02:35:33 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 02 Nov 2010 09:35:33 +0000 Subject: anyone using AsynchronousDatagramChannel? In-Reply-To: <4CCECD35.7020004@oracle.com> References: <4CC08DBB.9000904@oracle.com> <4CCECD35.7020004@oracle.com> Message-ID: <4CCFDB65.8060607@oracle.com> Alan Bateman wrote: > > Just to follow up on this one, the webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/6993126/webrev/ Alan, the changes look fine. -Chris. > > -Alan. From Alan.Bateman at oracle.com Sun Nov 7 04:14:33 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 07 Nov 2010 12:14:33 +0000 Subject: 6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException Message-ID: <4CD69829.607@oracle.com> I've been talking to Dag Wanvik (Derby/Java DB project) about some issues that they are seeing when threads doing I/O with a FileChannel are interrupted. They periodically see the channel being "silently closed" and also spurious ClosedByInterruptExceptions thrown by other threads doing I/O that are not interrupted. As it turns out there is a small rat's nest that has always been there. The following changes fix these issues so that ClosedByInterruptException is consistently thrown, and only by the thread that is interrupted. We may need to follow this up with a spec clarification for the case that a thread is interrupted at just around the time that an I/O completes. http://cr.openjdk.java.net/~alanb/6979009/webrev/ Thanks, Alan. From forax at univ-mlv.fr Sun Nov 7 07:24:44 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 07 Nov 2010 16:24:44 +0100 Subject: 6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException In-Reply-To: <4CD69829.607@oracle.com> References: <4CD69829.607@oracle.com> Message-ID: <4CD6C4BC.7040404@univ-mlv.fr> Le 07/11/2010 13:14, Alan Bateman a ?crit : > > I've been talking to Dag Wanvik (Derby/Java DB project) about some > issues that they are seeing when threads doing I/O with a FileChannel > are interrupted. They periodically see the channel being "silently > closed" and also spurious ClosedByInterruptExceptions thrown by other > threads doing I/O that are not interrupted. As it turns out there is a > small rat's nest that has always been there. The following changes fix > these issues so that ClosedByInterruptException is consistently > thrown, and only by the thread that is interrupted. We may need to > follow this up with a spec clarification for the case that a thread is > interrupted at just around the time that an I/O completes. > > http://cr.openjdk.java.net/~alanb/6979009/webrev/ > > Thanks, > Alan. There is another bug, closeLock is not final in AbstractInterruptibleChannel. Also in AbstractSelector and in AbstractInterruptibleChannel, this code: if (Thread.currentThread().isInterrupted()) interruptor.interrupt(Thread.currentThread()); can be changed to: Thread current = Thread.currentThread(); if (current.isInterrupted()) interruptor.interrupt(current); to avoid to call Threa.currentThread twice. About the patch, I'm not sure to fully understand it. R?mi From Alan.Bateman at oracle.com Sun Nov 7 11:58:09 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 07 Nov 2010 19:58:09 +0000 Subject: 6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException In-Reply-To: <4CD6C4BC.7040404@univ-mlv.fr> References: <4CD69829.607@oracle.com> <4CD6C4BC.7040404@univ-mlv.fr> Message-ID: <4CD704D1.1080604@oracle.com> R?mi Forax wrote: > : > There is another bug, closeLock is not final in > AbstractInterruptibleChannel. Thanks, I hadn't noticed that. I will fix that while I'm in the area. > > : > > can be changed to: > Thread current = Thread.currentThread(); > if (current.isInterrupted()) > interruptor.interrupt(current); > > to avoid to call Threa.currentThread twice. That is probably better. > > About the patch, I'm not sure to fully understand it. > The problem with the original implementation (this code is essentially unchanged since 1.4) is that closing the channel may cause several threads doing I/O on the same channel to observe the interrupted flag as false and so will throw ClosedByInterruptException. Alternatively, if some thread is just completing an I/O operation on the channel then it's invocation of the "end" method will reset the flag. The changes just mean that the intended thread will close the exception, other threads doing I/O on the channel at round the same time will close AsynchronousCloseException or have their I/O operations complete successfully. If several threads doing I/O on the channel are interrupted at around the same time then only one will throw ClosedByInterruptException. -Alan From xueming.shen at oracle.com Mon Nov 8 17:16:02 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 08 Nov 2010 17:16:02 -0800 Subject: 6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException In-Reply-To: <4CD69829.607@oracle.com> References: <4CD69829.607@oracle.com> Message-ID: <4CD8A0D2.5040809@oracle.com> 138 } catch (ClosedByInterruptException e) { 139 if (interruptible) { 140 if (Thread.currentThread().isInterrupted()) { 141 expected(e + " thrown and interrupt status set"); 142 } else { 143 unexpected(e + " thrown but interrupt status not set"); 144 } 145 } else { 146 expected(e); 147 } Shouldn't #146 be unexpected(e)? -Sherman On 11/7/2010 04:14, Alan Bateman wrote: > > I've been talking to Dag Wanvik (Derby/Java DB project) about some > issues that they are seeing when threads doing I/O with a FileChannel > are interrupted. They periodically see the channel being "silently > closed" and also spurious ClosedByInterruptExceptions thrown by other > threads doing I/O that are not interrupted. As it turns out there is a > small rat's nest that has always been there. The following changes fix > these issues so that ClosedByInterruptException is consistently > thrown, and only by the thread that is interrupted. We may need to > follow this up with a spec clarification for the case that a thread is > interrupted at just around the time that an I/O completes. > > http://cr.openjdk.java.net/~alanb/6979009/webrev/ > > Thanks, > Alan. From Alan.Bateman at oracle.com Tue Nov 9 01:28:05 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 09 Nov 2010 09:28:05 +0000 Subject: 6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException In-Reply-To: <4CD8A0D2.5040809@oracle.com> References: <4CD69829.607@oracle.com> <4CD8A0D2.5040809@oracle.com> Message-ID: <4CD91425.8040601@oracle.com> Xueming Shen wrote: > > 138 } catch (ClosedByInterruptException e) { > 139 if (interruptible) { > 140 if (Thread.currentThread().isInterrupted()) { > 141 expected(e + " thrown and interrupt > status set"); > 142 } else { > 143 unexpected(e + " thrown but interrupt > status not set"); > 144 } > 145 } else { > 146 expected(e); > 147 } > > Shouldn't #146 be unexpected(e)? Well spotted! I've fixed the test now. -Alan. From chris.hegarty at oracle.com Tue Nov 9 08:12:10 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 09 Nov 2010 16:12:10 +0000 Subject: 6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException In-Reply-To: <4CD704D1.1080604@oracle.com> References: <4CD69829.607@oracle.com> <4CD6C4BC.7040404@univ-mlv.fr> <4CD704D1.1080604@oracle.com> Message-ID: <4CD972DA.8010700@oracle.com> Alan Bateman wrote: > R?mi Forax wrote: >> : >> There is another bug, closeLock is not final in >> AbstractInterruptibleChannel. > Thanks, I hadn't noticed that. I will fix that while I'm in the area. > >> >> : >> >> can be changed to: >> Thread current = Thread.currentThread(); >> if (current.isInterrupted()) >> interruptor.interrupt(current); >> >> to avoid to call Threa.currentThread twice. > That is probably better. > >> >> About the patch, I'm not sure to fully understand it. >> > The problem with the original implementation (this code is essentially > unchanged since 1.4) is that closing the channel may cause several > threads doing I/O on the same channel to observe the interrupted flag as > false and so will throw ClosedByInterruptException. Alternatively, if > some thread is just completing an I/O operation on the channel then it's > invocation of the "end" method will reset the flag. The changes just > mean that the intended thread will close the exception, other threads > doing I/O on the channel at round the same time will close > AsynchronousCloseException or have their I/O operations complete > successfully. If several threads doing I/O on the channel are > interrupted at around the same time then only one will throw > ClosedByInterruptException. It seems unnecessary (but not wrong) to pass the current thread to the interruptor in AbstractSelector, null would be sufficient. Would it be overkill/wrong to have a list of interrupted threads? Instead of just the last interrupted thread getting ClosedByInterruptException. Otherwise, looks fine. -Chris. > > -Alan > From Alan.Bateman at oracle.com Tue Nov 9 08:33:30 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 09 Nov 2010 16:33:30 +0000 Subject: 6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException In-Reply-To: <4CD972DA.8010700@oracle.com> References: <4CD69829.607@oracle.com> <4CD6C4BC.7040404@univ-mlv.fr> <4CD704D1.1080604@oracle.com> <4CD972DA.8010700@oracle.com> Message-ID: <4CD977DA.9020301@oracle.com> Chris Hegarty wrote: > : > It seems unnecessary (but not wrong) to pass the current thread to the > interruptor in AbstractSelector, null would be sufficient. Yes, null would do too but it really doesn't matter because it's not used for this case. > > Would it be overkill/wrong to have a list of interrupted threads? > Instead of just the last interrupted thread getting > ClosedByInterruptException. It's only possible to close the channel once and only one thread should throw ClosedByInterruptException. If several threads doing I/O on the same channel are interrupted at around the same time then first thread, calling Thread.interrupt, to acquite clockLock will set the victim and it's that thread that will throw ClosedByInterruptException. To the other threads its just like an asynchronous close, irrespective of if they have been interrupted too. -Alan. From chris.hegarty at oracle.com Tue Nov 9 08:35:35 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 09 Nov 2010 16:35:35 +0000 Subject: 6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException In-Reply-To: <4CD977DA.9020301@oracle.com> References: <4CD69829.607@oracle.com> <4CD6C4BC.7040404@univ-mlv.fr> <4CD704D1.1080604@oracle.com> <4CD972DA.8010700@oracle.com> <4CD977DA.9020301@oracle.com> Message-ID: <4CD97857.1030405@oracle.com> OK, thanks Alan. I'm fine with the change. -Chris. Alan Bateman wrote: > Chris Hegarty wrote: >> : >> It seems unnecessary (but not wrong) to pass the current thread to the >> interruptor in AbstractSelector, null would be sufficient. > Yes, null would do too but it really doesn't matter because it's not > used for this case. > >> >> Would it be overkill/wrong to have a list of interrupted threads? >> Instead of just the last interrupted thread getting >> ClosedByInterruptException. > It's only possible to close the channel once and only one thread should > throw ClosedByInterruptException. If several threads doing I/O on the > same channel are interrupted at around the same time then first thread, > calling Thread.interrupt, to acquite clockLock will set the victim and > it's that thread that will throw ClosedByInterruptException. To the > other threads its just like an asynchronous close, irrespective of if > they have been interrupted too. > > -Alan. > > From chris.hegarty at oracle.com Tue Nov 9 08:40:18 2010 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 09 Nov 2010 16:40:18 +0000 Subject: 6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException In-Reply-To: <4CD977DA.9020301@oracle.com> References: <4CD69829.607@oracle.com> <4CD6C4BC.7040404@univ-mlv.fr> <4CD704D1.1080604@oracle.com> <4CD972DA.8010700@oracle.com> <4CD977DA.9020301@oracle.com> Message-ID: <4CD97972.60809@oracle.com> OK, thanks Alan. I'm fine with the change. -Chris. Alan Bateman wrote: > Chris Hegarty wrote: >> : >> It seems unnecessary (but not wrong) to pass the current thread to the >> interruptor in AbstractSelector, null would be sufficient. > Yes, null would do too but it really doesn't matter because it's not > used for this case. > >> >> Would it be overkill/wrong to have a list of interrupted threads? >> Instead of just the last interrupted thread getting >> ClosedByInterruptException. > It's only possible to close the channel once and only one thread should > throw ClosedByInterruptException. If several threads doing I/O on the > same channel are interrupted at around the same time then first thread, > calling Thread.interrupt, to acquite clockLock will set the victim and > it's that thread that will throw ClosedByInterruptException. To the > other threads its just like an asynchronous close, irrespective of if > they have been interrupted too. > > -Alan. > > From xueming.shen at oracle.com Tue Nov 9 09:46:38 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 09 Nov 2010 09:46:38 -0800 Subject: 6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException In-Reply-To: <4CD91425.8040601@oracle.com> References: <4CD69829.607@oracle.com> <4CD8A0D2.5040809@oracle.com> <4CD91425.8040601@oracle.com> Message-ID: <4CD988FE.2080108@oracle.com> 463 } catch (ClosedByInterruptException e) { 464 // target closed by interrupt as ClosedByInterruptException needs 465 // to be thrown after closing this channel. 466 assert !target.isOpen(); 467 try { 468 close(); 469 } catch (IOException ignore) { 470 // nothing we can do 471 } 472 throw e; You are invoking "close()" directly in this case when interrupted, instead of "marking" it closed as we do in all other cases. This might be a good thing to do as the spec says "the interruped channel to be closed" (release file lock, native resource...), but make the "transferToTrustChannel" special. Otherwise, the change looks good. -Sherman From xueming.shen at oracle.com Tue Nov 9 10:46:06 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 09 Nov 2010 10:46:06 -0800 Subject: 6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException In-Reply-To: <4CD988FE.2080108@oracle.com> References: <4CD69829.607@oracle.com> <4CD8A0D2.5040809@oracle.com> <4CD91425.8040601@oracle.com> <4CD988FE.2080108@oracle.com> Message-ID: <4CD996EE.1060502@oracle.com> On 11/09/2010 09:46 AM, Xueming Shen wrote: > > > 463 } catch (ClosedByInterruptException e) { > 464 // target closed by interrupt as > ClosedByInterruptException needs > 465 // to be thrown after closing this channel. > 466 assert !target.isOpen(); > 467 try { > 468 close(); > 469 } catch (IOException ignore) { > 470 // nothing we can do > 471 } > 472 throw e; > > > You are invoking "close()" directly in this case when interrupted, > instead of > "marking" it closed as we do in all other cases. This might be a good > thing to > do as the spec says "the interruped channel to be closed" (release > file lock, > native resource...), but make the "transferToTrustChannel" special. > > Otherwise, the change looks good. > > -Sherman > I took a second look of AbstractInterruptibleChannel.close(), it appears invoking "close()" directly here does not make any difference as what is done in "begin()". So ignore my above comment. Approved. -Sherman From Alan.Bateman at oracle.com Tue Nov 9 10:48:55 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 09 Nov 2010 18:48:55 +0000 Subject: 6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException In-Reply-To: <4CD988FE.2080108@oracle.com> References: <4CD69829.607@oracle.com> <4CD8A0D2.5040809@oracle.com> <4CD91425.8040601@oracle.com> <4CD988FE.2080108@oracle.com> Message-ID: <4CD99797.80305@oracle.com> Xueming Shen wrote: > > > : > > You are invoking "close()" directly in this case when interrupted, > instead of > "marking" it closed as we do in all other cases. This might be a good > thing to > do as the spec says "the interruped channel to be closed" (release > file lock, > native resource...), but make the "transferToTrustChannel" special. This is the transferTo case where the target is a FileChannel and the interrupt closes the target channel. In that case we can't have transferTo throw ClosedByChannelException but leave the channel open (channel here is the source channel). I realize this isn't pretty but I don't think we have another solution at the moment. There is further work to get asynchronous close and interrupt close working with the transfer method, these issue have been there since 1.4. -Alan. From xueming.shen at oracle.com Tue Nov 9 10:54:35 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 09 Nov 2010 10:54:35 -0800 Subject: 6979009: (fc) FileChannel.read() fails to throw ClosedByInterruptException In-Reply-To: <4CD99797.80305@oracle.com> References: <4CD69829.607@oracle.com> <4CD8A0D2.5040809@oracle.com> <4CD91425.8040601@oracle.com> <4CD988FE.2080108@oracle.com> <4CD99797.80305@oracle.com> Message-ID: <4CD998EB.1060402@oracle.com> On 11/09/2010 10:48 AM, Alan Bateman wrote: > Xueming Shen wrote: >> >> >> : >> >> You are invoking "close()" directly in this case when interrupted, >> instead of >> "marking" it closed as we do in all other cases. This might be a good >> thing to >> do as the spec says "the interruped channel to be closed" (release >> file lock, >> native resource...), but make the "transferToTrustChannel" special. > This is the transferTo case where the target is a FileChannel and the > interrupt closes the target channel. In that case we can't have > transferTo throw ClosedByChannelException but leave the channel open > (channel here is the source channel). I realize this isn't pretty but > I don't think we have another solution at the moment. There is further > work to get asynchronous close and interrupt close working with the > transfer method, these issue have been there since 1.4. > > -Alan. OK. From Alan.Bateman at oracle.com Mon Nov 15 04:08:13 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 15 Nov 2010 12:08:13 +0000 Subject: 6999915: TEST_BUG: test/java/nio/channels/AsynchronousSocketChannel/Leaky.java failed intermittently (win) Message-ID: <4CE122AD.8010902@oracle.com> This is a test fix, to address an illusive test failure that happens intermittently when running on legacy editions of Windows installed on fast machines. To understand the test failure requires a bit of background: 1. Legacy editions of Windows (XP and Windows Server 2003) don't support thread agnostic I/O. When an attempt is made to initiate an I/O operation on a non-pooled thread, as in this test, then it causes a task to be submitted to the thread pool so that the I/O operation is initiated on a pooled thread. 2. The default thread pool, as used by this test, is a cached thread pool and so creates threads as needed. 3. I/O operations on ByteBuffers that are backed by an array in the heap require copying the bytes in/out of temporary direct buffers. To avoid a malloc/free per I/O operation, the direct buffers are maintained in per-thread cache. In this test, each thread involved in an I/O operations ends up with one 1MB buffer in its cache. All combined, it is possible for the hread pool to grow to more than 64 threads, after which OutOfMemoryError is thrown because the tests limits the direct memory to 64MB. To avoid this, the test is changed to use a fixed thread pool of 4 threads with the worst case being each thread caches up to 8 1MB buffers over the 10k I/O operations that the test performs. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/6999915/webrev/ Thanks, Alan. From forax at univ-mlv.fr Mon Nov 15 05:01:15 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 15 Nov 2010 14:01:15 +0100 Subject: 6999915: TEST_BUG: test/java/nio/channels/AsynchronousSocketChannel/Leaky.java failed intermittently (win) In-Reply-To: <4CE122AD.8010902@oracle.com> References: <4CE122AD.8010902@oracle.com> Message-ID: <4CE12F1B.3060504@univ-mlv.fr> Le 15/11/2010 13:08, Alan Bateman a ?crit : > > This is a test fix, to address an illusive test failure that happens > intermittently when running on legacy editions of Windows installed on > fast machines. To understand the test failure requires a bit of > background: > > 1. Legacy editions of Windows (XP and Windows Server 2003) don't > support thread agnostic I/O. When an attempt is made to initiate an > I/O operation on a non-pooled thread, as in this test, then it causes > a task to be submitted to the thread pool so that the I/O operation is > initiated on a pooled thread. > > 2. The default thread pool, as used by this test, is a cached thread > pool and so creates threads as needed. > > 3. I/O operations on ByteBuffers that are backed by an array in the > heap require copying the bytes in/out of temporary direct buffers. To > avoid a malloc/free per I/O operation, the direct buffers are > maintained in per-thread cache. In this test, each thread involved in > an I/O operations ends up with one 1MB buffer in its cache. > > All combined, it is possible for the hread pool to grow to more than > 64 threads, after which OutOfMemoryError is thrown because the tests > limits the direct memory to 64MB. To avoid this, the test is changed > to use a fixed thread pool of 4 threads with the worst case being each > thread caches up to 8 1MB buffers over the 10k I/O operations that the > test performs. > > The webrev with the changes is here: > > http://cr.openjdk.java.net/~alanb/6999915/webrev/ > > Thanks, > > Alan. Looks OK. R?mi From Alan.Bateman at oracle.com Thu Nov 18 02:35:09 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Nov 2010 10:35:09 +0000 Subject: 7000913: (bf) CharBuffer.wrap, slice, position, slice leads to CharBuffer with incorrect offset Message-ID: <4CE5015D.7050405@oracle.com> This one came up on core-libs-dev yesterday [1]. If a CharBuffer is created by wrapping a CharSequence, the resulting buffer is sliced, and the slice further sliced when the position is non-zero, then the resulting CharBuffer doesn't have the correct offset. I'm not sure if John found this by inspection or ran into the issue. Here's the webrev with the changes, it's mostly an update to an existing test as this case seems to have been missed: http://cr.openjdk.java.net/~alanb/7000913/webrev/ Thanks, Alan. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-November/005243.html From forax at univ-mlv.fr Thu Nov 18 02:43:56 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 18 Nov 2010 11:43:56 +0100 Subject: 7000913: (bf) CharBuffer.wrap, slice, position, slice leads to CharBuffer with incorrect offset In-Reply-To: <4CE5015D.7050405@oracle.com> References: <4CE5015D.7050405@oracle.com> Message-ID: <4CE5036C.8060901@univ-mlv.fr> Le 18/11/2010 11:35, Alan Bateman a ?crit : > > This one came up on core-libs-dev yesterday [1]. If a CharBuffer is > created by wrapping a CharSequence, the resulting buffer is sliced, > and the slice further sliced when the position is non-zero, then the > resulting CharBuffer doesn't have the correct offset. I'm not sure if > John found this by inspection or ran into the issue. Here's the webrev > with the changes, it's mostly an update to an existing test as this > case seems to have been missed: > http://cr.openjdk.java.net/~alanb/7000913/webrev/ > > Thanks, > Alan. > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-November/005243.html Looks good. R?mi From Alan.Bateman at oracle.com Fri Nov 19 13:37:03 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Nov 2010 21:37:03 +0000 Subject: 6878369: (ch) AsynchronousSocketChannel read/write methods that specify timeouts should not throw IAE Message-ID: <4CE6EDFF.1010503@oracle.com> This one came up on the nio-discuss list some time ago. In AsynchronousSocketChannel, the methods that have a timeout parameter are specified to throw IAE when a negative timeout is used. This is inconsistent with how timeouts are specified in j.u.c. To fix this, we need to change these methods so that they treat values less than or equal to zero to mean that the I/O does not have a timeout. The implementation change is trivial and I've extended an existing test to exercise the code with several timeout values. The webrev is here: http://cr.openjdk.java.net/~alanb/6878369/webrev/ Thanks, Alan. From forax at univ-mlv.fr Mon Nov 22 05:39:33 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 22 Nov 2010 14:39:33 +0100 Subject: 6878369: (ch) AsynchronousSocketChannel read/write methods that specify timeouts should not throw IAE In-Reply-To: <4CE6EDFF.1010503@oracle.com> References: <4CE6EDFF.1010503@oracle.com> Message-ID: <4CEA7295.5090301@univ-mlv.fr> Le 19/11/2010 22:37, Alan Bateman a ?crit : > > This one came up on the nio-discuss list some time ago. In > AsynchronousSocketChannel, the methods that have a timeout parameter > are specified to throw IAE when a negative timeout is used. This is > inconsistent with how timeouts are specified in j.u.c. To fix this, we > need to change these methods so that they treat values less than or > equal to zero to mean that the I/O does not have a timeout. The > implementation change is trivial and I've extended an existing test to > exercise the code with several timeout values. The webrev is here: > http://cr.openjdk.java.net/~alanb/6878369/webrev/ > > Thanks, > Alan. Hi Alan, Patch looks Ok. R?mi From tigran.mkrtchyan at desy.de Fri Nov 26 07:07:40 2010 From: tigran.mkrtchyan at desy.de (Tigran Mkrtchyan) Date: Fri, 26 Nov 2010 16:07:40 +0100 Subject: sendfile is broken on solaris with -d64? Message-ID: <4CEFCD3C.1000506@desy.de> Dear NIO gurus, we observed some weird behavior with sendfile on a solaris box with 1.6.0_22 and 1.7.0 we notice, that with -d64 FileChannel.transferTo() method uses memory mapped file instead of using systems sendfile call. according to jdk/src/solaris/native/sun/nio/ch/FileChannelImpl.c, my_sendfile_func have initialized in initIDs() function: JNIEXPORT jlong JNICALL Java_sun_nio_ch_FileChannelImpl_initIDs(JNIEnv *env, jclass clazz) { jlong pageSize = sysconf(_SC_PAGESIZE); chan_fd = (*env)->GetFieldID(env, clazz, "fd", "Ljava/io/FileDescriptor;"); #ifdef __solaris__ if (dlopen("/usr/lib/libsendfile.so.1", RTLD_GLOBAL | RTLD_LAZY) != NULL) { my_sendfile_func = (sendfile_func*) dlsym(RTLD_DEFAULT, "sendfilev64"); } #endif #ifdef __linux__ my_sendfile64_func = (sendfile64_func*) dlsym(RTLD_DEFAULT, "sendfile64"); #endif return pageSize; } when I run with -d32 I can see that with dtrace ( I puted the probe on sysconf call): sun/nio/ch/FileChannelImpl.initIDs()J sun/nio/ch/FileChannelImpl.()V StubRoutines (1) libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x1c9 libjvm.so`__1cCosUos_exception_wrapper6FpFpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v2468_v_+0x27 libjvm.so`__1cJJavaCallsEcall6FpnJJavaValue_nMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x2f libjvm.so`__1cNinstanceKlassbBcall_class_initializer_impl6FnTinstanceKlassHandle_pnGThread__v_+0xce libjvm.so`__1cNinstanceKlassWcall_class_initializer6MpnGThread__v_+0x4f libjvm.so`__1cNinstanceKlassPinitialize_impl6FnTinstanceKlassHandle_pnGThread__v_+0x2cc libjvm.so`__1cNinstanceKlassKinitialize6MpnGThread__v_+0x6c libjvm.so`__1cMLinkResolverTresolve_static_call6FrnICallInfo_rnLKlassHandle_nMsymbolHandle_53bbpnGThread__v_+0xd3 libjvm.so`__1cMLinkResolverUresolve_invokestatic6FrnICallInfo_nSconstantPoolHandle_ipnGThread__v_+0x67 libjvm.so`__1cMLinkResolverOresolve_invoke6FrnICallInfo_nGHandle_nSconstantPoolHandle_inJBytecodesECode_pnGThread__v_+0x71 But I dont see that with -d64. As a result, pointer to my_sendfile_func still NULL and sendfile method returns UNSUPPORTED: #ifdef __solaris__ if (my_sendfile_func == NULL) { return IOS_UNSUPPORTED; } ... How this happens is a puzzle for me, as according to the code it called in a static block of jdk/src/share/classes/sun/nio/ch/FileChannelImpl.java: static { Util.load(); allocationGranularity = initIDs(); nd = new FileDispatcher(); isAMappedBufferField = Reflect.lookupField("java.nio.MappedByteBuffer", "isAMappedBuffer"); } here is my dtrace script: # dtrace -s s1.d -c "java -XX:+ExtendedDTraceProbes -d64 Send" # trace only calls with SC_PAGESIZE as argument pid$target::sysconf:entry / arg0 == 11 / { self->pagesize = 1; } pid$target::sysconf:return /self->pagesize/ { printf("sysconf: rc=%d", arg0); jstack(50, 500); self->pagesize = 0; } Regards, Tigran. From Alan.Bateman at oracle.com Fri Nov 26 07:41:21 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Nov 2010 15:41:21 +0000 Subject: sendfile is broken on solaris with -d64? In-Reply-To: <4CEFCD3C.1000506@desy.de> References: <4CEFCD3C.1000506@desy.de> Message-ID: <4CEFD521.4050109@oracle.com> Tigran Mkrtchyan wrote: > > > Dear NIO gurus, > > we observed some weird behavior with sendfile on a solaris box with > 1.6.0_22 and 1.7.0 > > we notice, that with -d64 FileChannel.transferTo() method uses memory > mapped file instead of > using systems sendfile call. Thanks for the bug report. The 64-bit libsendfile is in /lib/64 whereas this code was originally written to only attempt to load it from /usr/lib. Also with a 64-bit library the symbol is sendfilev64. I'm kinda surprised it hasn't been noticed before. I'll create a bug for this. -Alan From Alan.Bateman at oracle.com Mon Nov 29 08:27:38 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Nov 2010 16:27:38 +0000 Subject: 7003155: (fs) Paths.get() does not handle escaped octets correctly Message-ID: <4CF3D47A.1020207@oracle.com> The code for converting URIs to Paths in the Solaris/Linux file system provider is not correct. It's using the decoded path component of the URI (ie: de-quoted) and so must be converted from UTF-8. The webrev with the change is here: http://cr.openjdk.java.net/~alanb/7003155/webrev/ Thanks, Alan. From lists at laerad.com Tue Nov 30 03:15:11 2010 From: lists at laerad.com (Benedict Elliott Smith) Date: Tue, 30 Nov 2010 11:15:11 +0000 Subject: Path.startsWith() etc Message-ID: Hi, The UnixPath implementation behaves rather annoyingly when the argument is a different type of Path. Currently a java.nio.file.ProviderMismatchException is thrown, but for ease of use it would be preferable (to my mind) to simply return false. Given that the new Path APIs have been designed to make using different providers interchangeably and uniformly, does it seem sensible to make as many methods as possible "safe" with respect to interaction between provider types. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20101130/d1010162/attachment.html From Alan.Bateman at oracle.com Tue Nov 30 03:58:46 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 30 Nov 2010 11:58:46 +0000 Subject: Path.startsWith() etc In-Reply-To: References: Message-ID: <4CF4E6F6.5010901@oracle.com> Benedict Elliott Smith wrote: > Hi, > > The UnixPath implementation behaves rather annoyingly when the > argument is a different type of Path. > > Currently a java.nio.file.ProviderMismatchException is thrown, but for > ease of use it would be preferable (to my mind) to simply return false. The exception is expected: "Unless otherwise noted, invoking a method of any class or interface in this package created by one provider with a parameter that is an object created by another provider, will throw ProviderMismatchException" Changing things so that some methods, like startsWith, return false might be inconsistent. I'm curious how you ran into this as I assume there must be a bug somewhere. Another thing to mention is that we are currently missing startsWith(String), endsWith(String), something that has come up a few times. > > Given that the new Path APIs have been designed to make using > different providers interchangeably and uniformly, does it seem > sensible to make as many methods as possible "safe" with respect to > interaction between provider types. Although the API allows for different providers there is no requirement that these providers be interoperable (as one provider will not know anything about the representation of objects associated with other providers). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20101130/17e770d9/attachment.html From lists at laerad.com Tue Nov 30 04:32:14 2010 From: lists at laerad.com (Benedict Elliott Smith) Date: Tue, 30 Nov 2010 12:32:14 +0000 Subject: Path.startsWith() etc In-Reply-To: <4CF4E6F6.5010901@oracle.com> References: <4CF4E6F6.5010901@oracle.com> Message-ID: I disagree that this is inconsistent behaviour for methods which perform a simple test - paths from different providers cannot possibly be prefixes of each other, so returning false seems perfectly safe and sensible - and in keeping with (for instance) Object equality, which will ordinarily return false when comparing objects of a different type, rather than a ClassCastException or similar. I encountered this because I have implemented a number of custom file system providers for use in an internal application for replicating file changes between different locations over a number of different protocols. Certain locations only require changes from certain prefixes of other locations, and ideally this would be a straightforward startsWith() test, but instead I have to first get hold of the FileSystemProvider and test they are equal, which feels like a bad way to go about checking this. The Path objects themselves can more easily do this with e.g. an instanceof test, which they perform anyway. I can understand why methods composing/acting on two Path objects of a different type would fail, but I don't really see why simple tests should not. Also, whilst on the topic, I wonder about the sense of having *any* provider for *relative* paths. Conceptually paths whose roots are not a member of the set of roots of all known file systems really have no place being constrained in anyway. I would expect to be able to obtain a relative path from one file system and compose it with one from another without any errors occurring. As it is this is very messy, and requires creating a path completely in one file system, converting it to a String and passing it into a different provider to obtain a new Path. On 30 November 2010 11:58, Alan Bateman wrote: > Benedict Elliott Smith wrote: > > Hi, > > The UnixPath implementation behaves rather annoyingly when the argument > is a different type of Path. > > Currently a java.nio.file.ProviderMismatchException is thrown, but for > ease of use it would be preferable (to my mind) to simply return false. > > The exception is expected: > > "Unless otherwise noted, invoking a method of any class or interface in > this package created by one provider with a parameter that is an object > created by another provider, will throw ProviderMismatchException" > > Changing things so that some methods, like startsWith, return false might > be inconsistent. I'm curious how you ran into this as I assume there must be > a bug somewhere. Another thing to mention is that we are currently missing > startsWith(String), endsWith(String), something that has come up a few > times. > > > > Given that the new Path APIs have been designed to make using different > providers interchangeably and uniformly, does it seem sensible to make as > many methods as possible "safe" with respect to interaction between provider > types. > > Although the API allows for different providers there is no requirement > that these providers be interoperable (as one provider will not know > anything about the representation of objects associated with other > providers). > > -Alan. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20101130/f6fb10fd/attachment.html From Alan.Bateman at oracle.com Tue Nov 30 05:25:56 2010 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 30 Nov 2010 13:25:56 +0000 Subject: Path.startsWith() etc In-Reply-To: References: <4CF4E6F6.5010901@oracle.com> Message-ID: <4CF4FB64.7080805@oracle.com> Benedict Elliott Smith wrote: > I disagree that this is inconsistent behaviour for methods which > perform a simple test - paths from different providers cannot possibly > be prefixes of each other, so returning false seems perfectly safe and > sensible - and in keeping with (for instance) Object equality, which > will ordinarily return false when comparing objects of a different > type, rather than a ClassCastException or similar. > > I encountered this because I have implemented a number of custom file > system providers for use in an internal application for replicating > file changes between different locations over a number of different > protocols. Certain locations only require changes from certain > prefixes of other locations, and ideally this would be a > straightforward startsWith() test, but instead I have to first get > hold of the FileSystemProvider and test they are equal, which feels > like a bad way to go about checking this. The Path objects themselves > can more easily do this with e.g. an instanceof test, which they > perform anyway. So it is a virtual file system provider that is examining the path or is the application? > > I can understand why methods composing/acting on two Path objects of a > different type would fail, but I don't really see why simple tests > should not. > > Also, whilst on the topic, I wonder about the sense of having > /any/ provider for /relative/ paths. Conceptually paths whose roots > are not a member of the set of roots of all known file systems really > have no place being constrained in anyway. I would expect to be able > to obtain a relative path from one file system and compose it with one > from another without any errors occurring. As it is this is very > messy, and requires creating a path completely in one file system, > converting it to a String and passing it into a different provider to > obtain a new Path. I'm not aware of any general solution to that issue. Converting to Strings may be lossy but it's the only representation that each provider is required to be support (for exporting purposes). -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20101130/b8902e9a/attachment.html