From Alan.Bateman at oracle.com Sun Apr 1 12:44:31 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 01 Apr 2012 20:44:31 +0100 Subject: executor for AsynchronousFileChannel.open() In-Reply-To: References: Message-ID: <4F78B01F.1060800@oracle.com> On 31/03/2012 06:02, Zhong Yu wrote: > Hi there, > > Suppose I have 100 asyn file channels for reading (concurrently). All > my completion handlers are non-blocking and short. What kind of > executor is best for AsynchronousFileChannel.open()? > > My initial choice was a ThreadPoolExecutor with maximumPoolSize==P > where P is the number of processors, because it would be less > efficient to have more than P threads executing non-blocking tasks > (i.e. completion handlers). > > However the javadoc of AsynchronousFileChannel.open() states that > there could be other kinds of tasks submitted to the executor, and the > nature of these tasks are unclear. Then I'm lost. > > Any advice on an appropriate executor for my specific use case? > > Thanks, > Zhong Yu For compute tasks then a function of the number of cores or hardware threads is usually appropriate but for I/O operations then it's a lot more difficult to size the thread pool. It's possible that things may be dominated by file I/O and that may limit the number of completion handlers that you see running concurrently. The only I will say is that this is really 100 distinct AsynchronousFileChannel instances then you may wish to share a thread pool between them, especially if there is only 1 or a small number of concurrent I/O operations on each file. -Alan. From zhong.j.yu at gmail.com Mon Apr 2 14:41:14 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Mon, 2 Apr 2012 16:41:14 -0500 Subject: executor for AsynchronousFileChannel.open() In-Reply-To: <4F78B01F.1060800@oracle.com> References: <4F78B01F.1060800@oracle.com> Message-ID: On Sun, Apr 1, 2012 at 2:44 PM, Alan Bateman wrote: > On 31/03/2012 06:02, Zhong Yu wrote: >> >> Hi there, >> >> Suppose I have 100 asyn file channels for reading (concurrently). All >> my completion handlers are non-blocking and short. What kind of >> executor is best for AsynchronousFileChannel.open()? >> >> My initial choice was a ThreadPoolExecutor with maximumPoolSize==P >> where P is the number of processors, because it would be less >> efficient to have more than P threads executing non-blocking tasks >> (i.e. completion handlers). >> >> However the javadoc of AsynchronousFileChannel.open() states that >> there could be other kinds of tasks submitted to the executor, and the >> nature of these tasks are unclear. Then I'm lost. >> >> Any advice on an appropriate executor for my specific use case? >> >> Thanks, >> Zhong Yu > > For compute tasks then a function of the number of cores or hardware threads > is usually appropriate but for I/O operations then it's a lot more difficult Let's say my completion handlers do nothing but compute checksums of file content. In that case, can I use a ThreadPoolExecutor with maximumPoolSize == Runtime.availableProcessors()? Is there any assurance that no other tasks will be submitted to this executor? > to size the thread pool. It's possible that things may be dominated by file > I/O and that may limit the number of completion handlers that you see > running concurrently. The only I will say is that this is really 100 > distinct AsynchronousFileChannel instances then you may wish to share a > thread pool between them, especially if there is only 1 or a small number of > concurrent I/O operations on each file. Yes, a file channel is only read by one thread at any time, no concurrent activities; I intend to have all file channels share 1 executor, but not sure what kind of executor is good for the purpose. I know exactly the nature of my completion handlers, but I don't know if other tasks could be submitted to the executor. From jim.gish at oracle.com Wed Apr 4 06:29:50 2012 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 04 Apr 2012 09:29:50 -0400 Subject: [PATCH] 7133806 (fs) Typo in Files.newByteChannel javadoc In-Reply-To: <4F7B44EC.5010605@oracle.com> References: <4F7B44EC.5010605@oracle.com> Message-ID: <4F7C4CCE.90408@oracle.com> Description: just a trivial javadoc change Patch: diff --git a/src/share/classes/java/nio/file/Files.java b/src/share/classes/java/nio/file/Files.java --- a/src/share/classes/java/nio/file/Files.java +++ b/src/share/classes/java/nio/file/Files.java @@ -269,7 +269,7 @@ * WritableByteChannel wbc = Files.newByteChannel(path, EnumSet.of(CREATE,APPEND)); * * // create file with initial permissions, opening it for both reading and writing - * {@code FileAttribute<> perms = ...} + * {@code FileAttribute> perms = ...} * SeekableByteChannel sbc = Files.newByteChannel(path, EnumSet.of(CREATE_NEW,READ,WRITE), perms); * * Test: none required. Thanks, Jim Gish (P.S. this is my first attempt at this process -- please be gentle :-) ) From chris.hegarty at oracle.com Wed Apr 4 06:34:12 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 04 Apr 2012 14:34:12 +0100 Subject: [PATCH] 7133806 (fs) Typo in Files.newByteChannel javadoc In-Reply-To: <4F7C4CCE.90408@oracle.com> References: <4F7B44EC.5010605@oracle.com> <4F7C4CCE.90408@oracle.com> Message-ID: <4F7C4DD4.3010307@oracle.com> Thanks for the contribution Jim, looks fine to me. Are you an author for the jdk8 project? I think you should request to be, otherwise I can push this for you listing you as the contributor. -Chris. On 04/04/2012 14:29, Jim Gish wrote: > > Description: just a trivial javadoc change > > Patch: > > diff --git a/src/share/classes/java/nio/file/Files.java > b/src/share/classes/java/nio/file/Files.java > --- a/src/share/classes/java/nio/file/Files.java > +++ b/src/share/classes/java/nio/file/Files.java > @@ -269,7 +269,7 @@ > * WritableByteChannel wbc = Files.newByteChannel(path, > EnumSet.of(CREATE,APPEND)); > * > * // create file with initial permissions, opening it for > both reading and writing > - * {@code FileAttribute<> perms = ...} > + * {@code FileAttribute> perms = ...} > * SeekableByteChannel sbc = Files.newByteChannel(path, > EnumSet.of(CREATE_NEW,READ,WRITE), perms); > * > * > > Test: none required. > > Thanks, > Jim Gish > > (P.S. this is my first attempt at this process -- please be gentle :-) ) > > From chris.hegarty at oracle.com Thu Apr 5 06:04:06 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 05 Apr 2012 14:04:06 +0100 Subject: hg: jdk8/tl/jdk: 7133806: Typo in Files.newByteChannel javadoc In-Reply-To: <20120405125912.57B7747E19@hg.openjdk.java.net> References: <20120405125912.57B7747E19@hg.openjdk.java.net> Message-ID: <4F7D9846.3050201@oracle.com> [ I took the liberty of pushing this one for you Jim ] Congratulations on your first OpenJDK contribution. I'm sure there will be many more! -Chris. On 05/04/2012 13:58, chris.hegarty at oracle.com wrote: > Changeset: 92de69b24416 > Author: jgish > Date: 2012-04-05 13:57 +0100 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92de69b24416 > > 7133806: Typo in Files.newByteChannel javadoc > Reviewed-by: chegar > > ! src/share/classes/java/nio/file/Files.java > From Alan.Bateman at oracle.com Tue Apr 10 03:15:37 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Apr 2012 11:15:37 +0100 Subject: executor for AsynchronousFileChannel.open() In-Reply-To: References: <4F78B01F.1060800@oracle.com> Message-ID: <4F840849.30306@oracle.com> On 02/04/2012 22:41, Zhong Yu wrote: > : > Let's say my completion handlers do nothing but compute checksums of > file content. In that case, can I use a ThreadPoolExecutor with > maximumPoolSize == Runtime.availableProcessors()? Is there any > assurance that no other tasks will be submitted to this executor? The reason for the wording in the open method is to allow for highly varied implementations. For example, on Windows XP you may observe tasks being submitted to the thread pool to initiate I/O operations for cases where you attempt to initiate on non-pooled thread. On newer versions of Windows you don't observe this and you will only see tasks that are handling completion events and invoking your completion handlers. On Solaris/Linux/Mac then the default implementation of AsynchronousFileChannel isn't making direct use of kernel facilities at this time so you will observe tasks that last for the duration of the I/O operation. Hopefully it should start to become clear that it's not easy to provide general advice on the maximum pool size. You suggestion to start with Runtime.availableProcessors should be okay but I would suggest monitoring it to see how much concurrency you actually get. It may be that the I/O is too slow compared to the checksum computation, in which case you may not observe too many threads executing completion handlers concurrently. -Alan. From zhong.j.yu at gmail.com Tue Apr 10 08:12:04 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Tue, 10 Apr 2012 10:12:04 -0500 Subject: executor for AsynchronousFileChannel.open() In-Reply-To: <4F840849.30306@oracle.com> References: <4F78B01F.1060800@oracle.com> <4F840849.30306@oracle.com> Message-ID: Thanks Alan. You are right, in the context of heavy I/O operations, my concern about threading overhead of the lightweight tasks is overblown. I'll simply use the default thread pool with unbounded number of threads. However one problem is that these threads never expire class sun.nio.ch.ThreadPool static ThreadPool createDefault() { ExecutorService executor = new ThreadPoolExecutor(0, Integer.MAX_VALUE, Long.MAX_VALUE, TimeUnit.MILLISECONDS, new SynchronousQueue(), threadFactory); After peak load, the extra threads will stay forever. Some users might find that unsettling. Shouldn't we set a human-scale timeout, like 60 seconds? Cheers, Zhong Yu On Tue, Apr 10, 2012 at 5:15 AM, Alan Bateman wrote: > On 02/04/2012 22:41, Zhong Yu wrote: >> >> : >> Let's say my completion handlers do nothing but compute checksums of >> file content. In that case, can I use a ThreadPoolExecutor with >> maximumPoolSize == Runtime.availableProcessors()? Is there any >> assurance that no other tasks will be submitted to this executor? > > The reason for the wording in the open method is to allow for highly varied > implementations. For example, on Windows XP you may observe tasks being > submitted to the thread pool to initiate I/O operations for cases where you > attempt to initiate on non-pooled thread. On newer versions of Windows you > don't observe this and you will only see tasks that are handling completion > events and invoking your completion handlers. On Solaris/Linux/Mac then the > default implementation of AsynchronousFileChannel isn't making direct use of > kernel facilities at this time so you will observe tasks that last for the > duration of the I/O operation. Hopefully it should start to become clear > that it's not easy to provide general advice on the maximum pool size. You > suggestion to start with Runtime.availableProcessors should be okay but I > would suggest monitoring it to see how much concurrency you actually get. It > may be that the I/O is too slow compared to the checksum computation, in > which case you may not observe too many threads executing completion > handlers concurrently. > > -Alan. From Alan.Bateman at oracle.com Tue Apr 10 08:18:03 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Apr 2012 16:18:03 +0100 Subject: executor for AsynchronousFileChannel.open() In-Reply-To: References: <4F78B01F.1060800@oracle.com> <4F840849.30306@oracle.com> Message-ID: <4F844F2B.5020807@oracle.com> On 10/04/2012 16:12, Zhong Yu wrote: > Thanks Alan. You are right, in the context of heavy I/O operations, my > concern about threading overhead of the lightweight tasks is > overblown. > > I'll simply use the default thread pool with unbounded number of > threads. However one problem is that these threads never expire > > class sun.nio.ch.ThreadPool > static ThreadPool createDefault() { > > ExecutorService executor = > new ThreadPoolExecutor(0, Integer.MAX_VALUE, > Long.MAX_VALUE, TimeUnit.MILLISECONDS, > new SynchronousQueue(), > threadFactory); > > After peak load, the extra threads will stay forever. Some users might > find that unsettling. Shouldn't we set a human-scale timeout, like 60 > seconds? > It probably should, except for older versions of Windows where I/O operations are tied to the initiating thread so we can't let them terminate if there are outstanding I/O operations. -Alan. From Alan.Bateman at oracle.com Thu Apr 12 04:08:43 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Apr 2012 12:08:43 +0100 Subject: 7143744: (se) Stabilize KQueue SelectorProvider and make default on MacOSX Message-ID: <4F86B7BB.1000405@oracle.com> I need a reviewer for a patch that fixes several issues with the kqueue SelectorProvider. It also restores it to be the default SelectorProvider on MacOSX. Note that these changes are for jdk8. Once they have baked for a while in 8 then we should consider them for jdk7u too. As background, Apple contributed their kqueue SelectorProvider to the macosx-port project [1] as it's more scalable than the poll based SelectorProvider that the bsd-port project was using. Unfortunately the kqueue SelectorProvider had a few issues and there were several test failures. In the end the default was switched back to the poll SelectorProvider [2], pending resolution of these issues. I've finally got a chance to look at the issues and have a webrev with the changes here: http://cr.openjdk.java.net/~alanb/7143744/webrev The main issue is the SelectorProvider didn't work correctly with channels that are registered for more than one op at a time (OP_READ | OP_WRITE for example). If more than one event was retrieved for the same file descriptor then the ready ops were replaced rather than updated. This stems from having the same file descriptor associated with more than one filter. The return from the select or selectNow methods was incorrect for these cases too (double accounting). There were also intermittent CancelledKeyException issues when keys were canceled or channels closed at around the same time as a select. There was also an intermittent NullPointerException during wakeup. With these changes then all tests are passing. There is further clean-up that is required but it's not critical. In particular, the AsynchronousChannelProvider implementation [2] is also based on kqueue (in ONESHOT rather than level triggered mode) so there is an opportunity to remove some code, native code and wrapper in particular. I've deliberately not included this refactoring in this patch as it's more appropriate for jdk8. As I mentioned above, we will likely want to push this patch to jdk7u in the future so the changes have been kept to a minimum. Thank you, Alan. [1] http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/cb5ebc902d33 [2] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/98564f184614 [3] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/5599aa5a4a51 From Alan.Bateman at oracle.com Mon Apr 16 02:45:41 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Apr 2012 10:45:41 +0100 Subject: 7132924: (dc) DatagramChannel.disconnect throws SocketException with IPv4 socket and IPv6 enabled [macosx] Message-ID: <4F8BEA45.9070006@oracle.com> This is a small bug left over from the Mac port. If IPv6 is enabled and a DatagramChannel is created to an IPv4-only socket then the disconnect method fails with an "Invalid argument" error on Mac OS X. The issue is that the disconnect implementation is specifying AF_INET6 as the protocol family when IPv6 is enabled whereas it should select the family based on family of the socket that the DatagramChannel is using. The fix is trivial: http://cr.openjdk.java.net/~alanb/7132924/webrev/ Thanks, Alan. From Thomas.Salter at unisys.com Mon Apr 16 06:49:07 2012 From: Thomas.Salter at unisys.com (Salter, Thomas A) Date: Mon, 16 Apr 2012 08:49:07 -0500 Subject: DatagramChannel Message-ID: <63D5DCACD1E9E34C89C8203C64F521C3FECB44DD8C@USEA-EXCH7.na.uis.unisys.com> [I'm not sure if I should post this to net-dev, nio-dev or something else, so I posted to both.] I have a trivial DatagramChannel program that fails on Windows if run with Java.net.preferIPv6Addresses=true. The exception and code are included below. The problem is that when the bind parameter is null, DatagramChannelImpl calls new InetSocketAddress(0), but that returns an AF_INET6 address when preferIPv6Addresses=true. Even when the caller passes a SocketAddress to bind, it's hard to get it right if you want to specify the any address or the loopback address. The methods to get these addresses all change their behavior based on the setting of preferIPv6Addresses. I'd be inclined to believe it's a user error to specify an address family on open and then pass a different address family on bind, except that the TCK does exactly this. It opens with AF_INET and then passes any and loopback addresses in AF_INET6 format. I also wonder why it's even an option to specify an explicit address family. According to the Java Docs this is the only place in the entire JDK that doesn't just infer the family from an address. There's no other references to ProtocolFamily and StandardProtocolFamily. java.net.SocketException: Address family not supported by protocol family: bind at sun.nio.ch.Net.bind0(Native Method) at sun.nio.ch.Net.bind(Net.java:344) at sun.nio.ch.DatagramChannelImpl.bind(DatagramChannelImpl.java:672) at DatagramChannelTest.main(DatagramChannelTest.java:14) import java.io.*; import java.net.*; import java.nio.channels.*; import static java.lang.System.out; public class DatagramChannelTest { public static void main(String[] args) { DatagramChannel dgc; try { dgc = DatagramChannel.open( StandardProtocolFamily.INET ); dgc.bind( null ); out.println("dgc:" + dgc.getLocalAddress() ); } catch( IOException e ) { // TODO Auto-generated catch block e.printStackTrace(); } } } This was run on Windows 7 with Java 7: java version "1.7.0_03" Java(TM) SE Runtime Environment (build 1.7.0_03-b05) Java HotSpot(TM) Client VM (build 22.1-b02, mixed mode, sharing) Tom Salter | Software Engineer | Java & Middleware Development Unisys | 2476 Swedesford Road | Malvern, PA 19355 | 610-648-2568 | N385-2568 [cid:image001.gif at 01CD1BB2.56799670] THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120416/399931f3/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2511 bytes Desc: image001.gif Url : http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120416/399931f3/image001.gif From Alan.Bateman at oracle.com Mon Apr 16 07:21:14 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Apr 2012 15:21:14 +0100 Subject: DatagramChannel In-Reply-To: <63D5DCACD1E9E34C89C8203C64F521C3FECB44DD8C@USEA-EXCH7.na.uis.unisys.com> References: <63D5DCACD1E9E34C89C8203C64F521C3FECB44DD8C@USEA-EXCH7.na.uis.unisys.com> Message-ID: <4F8C2ADA.6030707@oracle.com> On 16/04/2012 14:49, Salter, Thomas A wrote: > : > > > I also wonder why it's even an option to specify an explicit address > family. According to the Java Docs this is the only place in the > entire JDK that doesn't just infer the family from an address. > There's no other references to ProtocolFamily and StandardProtocolFamily. On Windows issue then which version of Windows do you see this? On the ProtocolFamily then this is part of the multicast support that was added in JDK7. Here's how it's worded in MulticastChannel: "The creation of the channel should specify the |ProtocolFamily| that corresponds to the address type of the multicast groups that the channel will join. There is no guarantee that a channel to a socket in one protocol family can join and receive multicast datagrams when the address of the multicast group corresponds to another protocol family. For example, it is implementation specific if a channel to an |IPv6| socket can join an |IPv4| multicast group and receive multicast datagrams sent to the group." In time then one could envisage being able to create classic DatagramSocket or MulticastSocket instances to an IPv4 only or IPv6 only socket. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120416/7edb1343/attachment-0001.html From rob.mckenna at oracle.com Mon Apr 16 07:25:39 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 16 Apr 2012 15:25:39 +0100 Subject: RFR: 7118373: (se) Potential leak file descriptor when deregistrating at around the same time as an async close Message-ID: <4F8C2BE3.1010302@oracle.com> Hi folks, Webrev: http://cr.openjdk.java.net/~robm/7118373/webrev.00/ In a multi-threaded environment if thread a) cancels a SelectionKey and then closes a SocketChannel (for example) we can run into a problem if another thread (b) calls Selector.select() just after AbstractInterruptibleChannel.close() starts running. When this happens, open has been set to false but implCloseChannel() has not yet executed. If thread b) starts running at this point the select() will kill() the socket by way of the deregister queue. Since implCloseSelectableChannel() will then proceed to dup2 this fd we're left with a leaking socket as the ST_KILLED has already been set so our subsequent call to SocketChannelImpl.kill() will simply return. The call to kill() from AbstractPollSelectorImpl.implDereg() is necessary to properly deal with SelectableChannels whose reader/writerThread's were blocked in IO during a call to close(). The fix resolves this problem by checking that we haven't already killed this SelectableChannel before we attempt to dup2 its fd. -Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120416/e07498e0/attachment.html From michael.x.mcmahon at oracle.com Mon Apr 16 07:47:30 2012 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 16 Apr 2012 15:47:30 +0100 Subject: 7143744: (se) Stabilize KQueue SelectorProvider and make default on MacOSX In-Reply-To: <4F86B7BB.1000405@oracle.com> References: <4F86B7BB.1000405@oracle.com> Message-ID: <4F8C3102.10108@oracle.com> The change looks good to me. - Michael. On 12/04/12 12:08, Alan Bateman wrote: > > I need a reviewer for a patch that fixes several issues with the > kqueue SelectorProvider. It also restores it to be the default > SelectorProvider on MacOSX. Note that these changes are for jdk8. Once > they have baked for a while in 8 then we should consider them for > jdk7u too. > > As background, Apple contributed their kqueue SelectorProvider to the > macosx-port project [1] as it's more scalable than the poll based > SelectorProvider that the bsd-port project was using. Unfortunately > the kqueue SelectorProvider had a few issues and there were several > test failures. In the end the default was switched back to the poll > SelectorProvider [2], pending resolution of these issues. > > I've finally got a chance to look at the issues and have a webrev with > the changes here: > http://cr.openjdk.java.net/~alanb/7143744/webrev > > The main issue is the SelectorProvider didn't work correctly with > channels that are registered for more than one op at a time (OP_READ | > OP_WRITE for example). If more than one event was retrieved for the > same file descriptor then the ready ops were replaced rather than > updated. This stems from having the same file descriptor associated > with more than one filter. The return from the select or selectNow > methods was incorrect for these cases too (double accounting). There > were also intermittent CancelledKeyException issues when keys were > canceled or channels closed at around the same time as a select. There > was also an intermittent NullPointerException during wakeup. > > With these changes then all tests are passing. There is further > clean-up that is required but it's not critical. In particular, the > AsynchronousChannelProvider implementation [2] is also based on kqueue > (in ONESHOT rather than level triggered mode) so there is an > opportunity to remove some code, native code and wrapper in > particular. I've deliberately not included this refactoring in this > patch as it's more appropriate for jdk8. As I mentioned above, we will > likely want to push this patch to jdk7u in the future so the changes > have been kept to a minimum. > > Thank you, > Alan. > > [1] > http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/cb5ebc902d33 > [2] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/98564f184614 > [3] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/5599aa5a4a51 From Alan.Bateman at oracle.com Mon Apr 16 08:13:26 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Apr 2012 16:13:26 +0100 Subject: RFR: 7118373: (se) Potential leak file descriptor when deregistrating at around the same time as an async close In-Reply-To: <4F8C2BE3.1010302@oracle.com> References: <4F8C2BE3.1010302@oracle.com> Message-ID: <4F8C3716.1040807@oracle.com> On 16/04/2012 15:25, Rob McKenna wrote: > Hi folks, > > Webrev: > http://cr.openjdk.java.net/~robm/7118373/webrev.00/ Thanks for taking this one, the change looks good to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120416/61d62388/attachment.html From Alan.Bateman at oracle.com Mon Apr 16 08:38:45 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Apr 2012 16:38:45 +0100 Subject: 7143744: (se) Stabilize KQueue SelectorProvider and make default on MacOSX In-Reply-To: <4F8C3102.10108@oracle.com> References: <4F86B7BB.1000405@oracle.com> <4F8C3102.10108@oracle.com> Message-ID: <4F8C3D05.9030107@oracle.com> On 16/04/2012 15:47, Michael McMahon wrote: > The change looks good to me. > > - Michael. Thanks Michael. Chris mentioned off-list that the copyright headers are missing the classpath exception. I hadn't noticed this so I've fixed them and updated the webrev: http://cr.openjdk.java.net/~alanb/7143744/webrev/ -Alan. From chris.hegarty at oracle.com Mon Apr 16 09:05:23 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 16 Apr 2012 17:05:23 +0100 Subject: 7143744: (se) Stabilize KQueue SelectorProvider and make default on MacOSX In-Reply-To: <4F8C3D05.9030107@oracle.com> References: <4F86B7BB.1000405@oracle.com> <4F8C3102.10108@oracle.com> <4F8C3D05.9030107@oracle.com> Message-ID: <4F8C4343.2070202@oracle.com> On 16/04/2012 16:38, Alan Bateman wrote: > On 16/04/2012 15:47, Michael McMahon wrote: >> The change looks good to me. >> >> - Michael. > Thanks Michael. Chris mentioned off-list that the copyright headers are > missing the classpath exception. I hadn't noticed this so I've fixed Thanks, I'm fine with this change too. You could use autoboxing for the int value being passed to fdMap get/remove, but I think the compiler will generate the same code either way. Good to see the kqueue SelectorProvider being made the default. -Chris. > them and updated the webrev: > > http://cr.openjdk.java.net/~alanb/7143744/webrev/ > > -Alan. From Alan.Bateman at oracle.com Mon Apr 16 09:52:52 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Apr 2012 17:52:52 +0100 Subject: DatagramChannel In-Reply-To: <63D5DCACD1E9E34C89C8203C64F521C3FECB44DD8C@USEA-EXCH7.na.uis.unisys.com> References: <63D5DCACD1E9E34C89C8203C64F521C3FECB44DD8C@USEA-EXCH7.na.uis.unisys.com> Message-ID: <4F8C4E64.50905@oracle.com> On 16/04/2012 14:49, Salter, Thomas A wrote: > > [I'm not sure if I should post this to net-dev, nio-dev or something > else, so I posted to both.] > > I have a trivial DatagramChannel program that fails on Windows if run > with Java.net.preferIPv6Addresses=true. The exception and code are > included below. > > The problem is that when the bind parameter is null, > DatagramChannelImpl calls new InetSocketAddress(0), but that returns > an AF_INET6 address when preferIPv6Addresses=true. Even when the > caller passes a SocketAddress to bind, it's hard to get it right if > you want to specify the any address or the loopback address. The > methods to get these addresses all change their behavior based on the > setting of preferIPv6Addresses. > > Just to confirm that this duplicates on Solaris and Mac too. We'll need to change the bind method so that the null case uses InetAddress.getByName("0.0.0.0") when the DatagramChannel is connected to an IPv4 socket. I'll create a bug for this. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120416/78458b66/attachment.html From chris.hegarty at oracle.com Tue Apr 17 04:09:08 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 17 Apr 2012 12:09:08 +0100 Subject: 7132924: (dc) DatagramChannel.disconnect throws SocketException with IPv4 socket and IPv6 enabled [macosx] In-Reply-To: <4F8BEA45.9070006@oracle.com> References: <4F8BEA45.9070006@oracle.com> Message-ID: <4F8D4F54.2090707@oracle.com> Looks good to me. -Chris. On 16/04/12 10:45, Alan Bateman wrote: > > This is a small bug left over from the Mac port. If IPv6 is enabled and > a DatagramChannel is created to an IPv4-only socket then the disconnect > method fails with an "Invalid argument" error on Mac OS X. The issue is > that the disconnect implementation is specifying AF_INET6 as the > protocol family when IPv6 is enabled whereas it should select the family > based on family of the socket that the DatagramChannel is using. The fix > is trivial: > > http://cr.openjdk.java.net/~alanb/7132924/webrev/ > > Thanks, > Alan. From Alan.Bateman at oracle.com Tue Apr 17 13:10:40 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 Apr 2012 21:10:40 +0100 Subject: Typo in javadoc of Path.java In-Reply-To: <20120417191323.163540@gmx.net> References: <20120417191323.163540@gmx.net> Message-ID: <4F8DCE40.3010902@oracle.com> On 17/04/2012 20:13, Alexander Thaller wrote: > Hello. > I think that in the javadoc for the class Path in /jdk/src/share/classes/java/nio/file/Path.java there is a typo in the last line of the third paragraph. Instead of "[...] the {@link #startsWith startsWith} and {@link #endsWith endWith} methods." it should read "[...] the {@link #startsWith startsWith} and {@link #endsWith endsWith} methods.". Notice the change of "{@link #endsWith endWith}" to "{@link #endsWith endsWith}". > Cheers. > Thaller Alexander Thanks, I'll create a bug to remember this. -Alan. From paul.sandoz at oracle.com Thu Apr 19 05:57:27 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 19 Apr 2012 14:57:27 +0200 Subject: Review fix for 7162262 Re: Typo in javadoc of Path.java In-Reply-To: <4F8DCE40.3010902@oracle.com> References: <20120417191323.163540@gmx.net> <4F8DCE40.3010902@oracle.com> Message-ID: Hi, http://cr.openjdk.java.net/~psandoz/7162262/webrev.0/ The addition of this one character probably produced over 10000 fold in character meta-data :-) Paul. On Apr 17, 2012, at 10:10 PM, Alan Bateman wrote: > On 17/04/2012 20:13, Alexander Thaller wrote: >> Hello. >> I think that in the javadoc for the class Path in /jdk/src/share/classes/java/nio/file/Path.java there is a typo in the last line of the third paragraph. Instead of "[...] the {@link #startsWith startsWith} and {@link #endsWith endWith} methods." it should read "[...] the {@link #startsWith startsWith} and {@link #endsWith endsWith} methods.". Notice the change of "{@link #endsWith endWith}" to "{@link #endsWith endsWith}". >> Cheers. >> Thaller Alexander > Thanks, I'll create a bug to remember this. > > -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20120419/149b1981/attachment.html From Alan.Bateman at oracle.com Thu Apr 19 06:15:42 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 19 Apr 2012 14:15:42 +0100 Subject: Review fix for 7162262 Re: Typo in javadoc of Path.java In-Reply-To: References: <20120417191323.163540@gmx.net> <4F8DCE40.3010902@oracle.com> Message-ID: <4F900FFE.2070606@oracle.com> On 19/04/2012 13:57, Paul Sandoz wrote: > Hi, > > http://cr.openjdk.java.net/~psandoz/7162262/webrev.0/ > > > The addition of this one character probably produced over 10000 fold > in character meta-data :-) > > Paul. > Thanks Paul, I'll push this for you now. -Alan.