From zhong.j.yu at gmail.com Sun Jun 8 23:57:10 2014 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Sun, 8 Jun 2014 18:57:10 -0500 Subject: File timestamp precision on Linux? Message-ID: Apparently, Java8 reports Linux file timestamps only in SECOND precision? Am I doing something wrong? Java version: java version "1.8.0_20-ea" Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.20-b17, mixed mode) Linux version: Linux 3.10.40-50.136.amzn1.x86_64 x86_64 (an amazon aws micro instance) Test Code: Path filePath = Paths.get("test.html"); BasicFileAttributes attrs = Files.readAttributes(filePath, BasicFileAttributes.class); FileTime time = attrs.lastModifiedTime(); Instant instant = time.toInstant(); System.out.println(instant); which prints 2014-06-08T23:45:03Z but the OS apparently supports nano precision: > stat test.html Access: 2014-06-08 23:45:02.718953224 +0000 Modify: 2014-06-08 23:45:03.358934113 +0000 Zhong Yu From Alan.Bateman at oracle.com Mon Jun 9 06:42:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 09 Jun 2014 07:42:02 +0100 Subject: File timestamp precision on Linux? In-Reply-To: References: Message-ID: <5395573A.2080408@oracle.com> On 09/06/2014 00:57, Zhong Yu wrote: > Apparently, Java8 reports Linux file timestamps only in SECOND > precision? Am I doing something wrong? > > Java version: > > java version "1.8.0_20-ea" > Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.20-b17, mixed mode) > > Linux version: > Linux 3.10.40-50.136.amzn1.x86_64 x86_64 > (an amazon aws micro instance) It supports higher precision timestamps too. Can you run locally and print out the value of "time"? I wonder if the issue is AWS or something else (like toInstant) -Alan From xueming.shen at oracle.com Mon Jun 9 17:51:23 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 09 Jun 2014 10:51:23 -0700 Subject: File timestamp precision on Linux? In-Reply-To: <5395573A.2080408@oracle.com> References: <5395573A.2080408@oracle.com> Message-ID: <5395F41B.4040108@oracle.com> On 06/08/2014 11:42 PM, Alan Bateman wrote: > On 09/06/2014 00:57, Zhong Yu wrote: >> Apparently, Java8 reports Linux file timestamps only in SECOND >> precision? Am I doing something wrong? >> >> Java version: >> >> java version "1.8.0_20-ea" >> Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b17) >> Java HotSpot(TM) 64-Bit Server VM (build 25.20-b17, mixed mode) >> >> Linux version: >> Linux 3.10.40-50.136.amzn1.x86_64 x86_64 >> (an amazon aws micro instance) > It supports higher precision timestamps too. Can you run locally and print out the value of "time"? I wonder if the issue is AWS or something else (like toInstant) > > -Alan > > Instant now = Instant.now(); FileTime nowFT = FileTime.from(now); System.out.println(" Instant.now():" + now); System.out.println("FileTime.from(Instant.now).toInstant():" + nowFT.toInstant()); Files.setLastModifiedTime(filePath, nowFT); BasicFileAttributes attrs = Files.readAttributes(filePath, BasicFileAttributes.class); FileTime time = attrs.lastModifiedTime(); System.out.println(); System.out.println(" ft:" + time.toInstant()); System.out.println("ins:" + time.toInstant()); --> Instant.now():2014-06-09T17:49:45.795Z FileTime.from(Instant.now).toInstant():2014-06-09T17:49:45.795Z ft:2014-06-09T17:49:45Z ins:2014-06-09T17:49:45Z So, something else is not likely to be "toInstant" :-) -Sherman From xueming.shen at oracle.com Mon Jun 9 18:13:03 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 09 Jun 2014 11:13:03 -0700 Subject: File timestamp precision on Linux? In-Reply-To: <5395F41B.4040108@oracle.com> References: <5395573A.2080408@oracle.com> <5395F41B.4040108@oracle.com> Message-ID: <5395F92F.7030809@oracle.com> On 06/09/2014 10:51 AM, Xueming Shen wrote: > On 06/08/2014 11:42 PM, Alan Bateman wrote: >> On 09/06/2014 00:57, Zhong Yu wrote: >>> Apparently, Java8 reports Linux file timestamps only in SECOND >>> precision? Am I doing something wrong? >>> >>> Java version: >>> >>> java version "1.8.0_20-ea" >>> Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b17) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.20-b17, mixed mode) >>> >>> Linux version: >>> Linux 3.10.40-50.136.amzn1.x86_64 x86_64 >>> (an amazon aws micro instance) >> It supports higher precision timestamps too. Can you run locally and print out the value of "time"? I wonder if the issue is AWS or something else (like toInstant) >> >> -Alan >> >> > Instant now = Instant.now(); > FileTime nowFT = FileTime.from(now); > System.out.println(" Instant.now():" + now); > System.out.println("FileTime.from(Instant.now).toInstant():" + nowFT.toInstant()); > > Files.setLastModifiedTime(filePath, nowFT); > BasicFileAttributes attrs = Files.readAttributes(filePath, BasicFileAttributes.class); > FileTime time = attrs.lastModifiedTime(); > System.out.println(); > System.out.println(" ft:" + time.toInstant()); > System.out.println("ins:" + time.toInstant()); > > --> > > Instant.now():2014-06-09T17:49:45.795Z > FileTime.from(Instant.now).toInstant():2014-06-09T17:49:45.795Z > > ft:2014-06-09T17:49:45Z > ins:2014-06-09T17:49:45Z > > > So, something else is not likely to be "toInstant" :-) > > -Sherman oh, to be clear, I'm on a 32-bit linux, so the system stat probably works for a second precision. -Sherman From Alan.Bateman at oracle.com Mon Jun 9 20:00:31 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 09 Jun 2014 21:00:31 +0100 Subject: File timestamp precision on Linux? In-Reply-To: <5395F92F.7030809@oracle.com> References: <5395573A.2080408@oracle.com> <5395F41B.4040108@oracle.com> <5395F92F.7030809@oracle.com> Message-ID: <5396125F.1090800@oracle.com> On 09/06/2014 19:13, Xueming Shen wrote: > > oh, to be clear, I'm on a 32-bit linux, so the system stat probably > works for a second precision. I think I see what is going on. It's that the Oracle downloads of JDK 8 are built on an older distribution (as Oracle binaries have to work on a large range of distributions). This will sort itself out soon once for JDK 9 builds once the build platform/compiler upgrade is done [1]. To resolve it on JDK 8 requires using a JDK build that is built for the distribution. -Alan [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000802.html From weijun.wang at oracle.com Fri Jun 13 09:07:44 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 13 Jun 2014 17:07:44 +0800 Subject: Deregister a key immediately? Message-ID: <814F19DC-8145-4398-A430-D61468C9067D@oracle.com> Hi I am using NIO Selector to monitor several channels. Whenever an exception is thrown on one channel I call key.cancel(). At the beginning of the loop I also call selector.keys.isEmpty() to see if there are channels still working. However, it seems key.cancel() does not automatically remove it from selector.keys() so I add a dummy selector.select(1) after the cancel call. Until now I didn't find it harmful but is there another way to deregister the key without calling select()? Or, I should not rely on selector.keys.isEmpty()? Thanks Max From Alan.Bateman at oracle.com Fri Jun 13 09:25:06 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Jun 2014 10:25:06 +0100 Subject: Deregister a key immediately? In-Reply-To: <814F19DC-8145-4398-A430-D61468C9067D@oracle.com> References: <814F19DC-8145-4398-A430-D61468C9067D@oracle.com> Message-ID: <539AC372.8000209@oracle.com> On 13/06/2014 10:07, Wang Weijun wrote: > Hi > > I am using NIO Selector to monitor several channels. Whenever an exception is thrown on one channel I call key.cancel(). At the beginning of the loop I also call selector.keys.isEmpty() to see if there are channels still working. However, it seems key.cancel() does not automatically remove it from selector.keys() so I add a dummy selector.select(1) after the cancel call. Until now I didn't find it harmful but is there another way to deregister the key without calling select()? > No, you have to select (or selectNow) in order to flush the key. I don't I understand your comment about using isEmpty "to see if there are channels still working", maybe you could expand on that. Also when you say you get an exception then if this is an IOException (connection reset for example) then I would think the best thing is to just close the channel. The Selector will clean-up on the next select. -Alan. From weijun.wang at oracle.com Fri Jun 13 10:07:46 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 13 Jun 2014 18:07:46 +0800 Subject: Deregister a key immediately? In-Reply-To: <539AC372.8000209@oracle.com> References: <814F19DC-8145-4398-A430-D61468C9067D@oracle.com> <539AC372.8000209@oracle.com> Message-ID: On Jun 13, 2014, at 17:25, Alan Bateman wrote: > On 13/06/2014 10:07, Wang Weijun wrote: >> Hi >> >> I am using NIO Selector to monitor several channels. Whenever an exception is thrown on one channel I call key.cancel(). At the beginning of the loop I also call selector.keys.isEmpty() to see if there are channels still working. However, it seems key.cancel() does not automatically remove it from selector.keys() so I add a dummy selector.select(1) after the cancel call. Until now I didn't find it harmful but is there another way to deregister the key without calling select()? >> > No, you have to select (or selectNow) in order to flush the key. > > I don't I understand your comment about using isEmpty "to see if there are channels still working", maybe you could expand on that. Some channels are connecting (OP_CONNECT) some are reading (OP_READ). If all of them already fails (exception thrown) I don't need to wait anymore. > Also when you say you get an exception then if this is an IOException (connection reset for example) then I would think the best thing is to just close the channel. The Selector will clean-up on the next select. OK I can close it, but it could throw an exception and I'm not sure the next select() will automatically deregister it. I'll call both for safety. Anyway, if I understand correctly, if I call selectNow() and do not touch the selectedKeys(), it won't have any affect on the next select() call, right? The next select() will still return the same value and selectedKeys() are the same since I haven't remove any of them. Thanks Max > > -Alan. From weijun.wang at oracle.com Mon Jun 23 05:15:42 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 23 Jun 2014 13:15:42 +0800 Subject: Name lookup is still blocking Message-ID: <699DBEB5-6971-4A1B-AA3C-D832A5046432@oracle.com> I'm using non-blocking SocketChannel (and DatagramChannel) to connect to multiple servers. The argument in SocketChannel.connect(remote) is a SocketAddress, and creating a normal InetSocketAddress object is still blocking. I see there is a InetSocketAddress.createUnresolved() method but calling SocketChannel.connec() upon such an address always throws an UnresolvedAddressException. It seems the sun.nio.ch.Net.checkAddress() method does not try to resolve it at all. Is there a way to make the name lookup process also non-blocking? Otherwise, if my server list contains a slow-resolving one at 1st position and a faster one at 2nd, there is still no chance for the 2nd one to be picked up. Thanks Max From chris.hegarty at oracle.com Mon Jun 23 07:57:26 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 23 Jun 2014 08:57:26 +0100 Subject: Name lookup is still blocking In-Reply-To: <699DBEB5-6971-4A1B-AA3C-D832A5046432@oracle.com> References: <699DBEB5-6971-4A1B-AA3C-D832A5046432@oracle.com> Message-ID: <53A7DDE6.4070900@oracle.com> On 23/06/14 06:15, Wang Weijun wrote: > I'm using non-blocking SocketChannel (and DatagramChannel) to connect to multiple servers. The argument in SocketChannel.connect(remote) is a SocketAddress, and creating a normal InetSocketAddress object is still blocking. I see there is a InetSocketAddress.createUnresolved() method but calling SocketChannel.connec() upon such an address always throws an UnresolvedAddressException. It seems the sun.nio.ch.Net.checkAddress() method does not try to resolve it at all. > > Is there a way to make the name lookup process also non-blocking? Not that I am aware of. -Chris > Otherwise, if my server list contains a slow-resolving one at 1st position and a faster one at 2nd, there is still no chance for the 2nd one to be picked up. > > Thanks > Max > > From fweimer at redhat.com Mon Jun 23 07:59:50 2014 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 23 Jun 2014 09:59:50 +0200 Subject: Name lookup is still blocking In-Reply-To: <699DBEB5-6971-4A1B-AA3C-D832A5046432@oracle.com> References: <699DBEB5-6971-4A1B-AA3C-D832A5046432@oracle.com> Message-ID: <53A7DE76.1000606@redhat.com> On 06/23/2014 07:15 AM, Wang Weijun wrote: > Is there a way to make the name lookup process also non-blocking? No, the underlying operating system interfaces typically support only blocking name lookups. -- Florian Weimer / Red Hat Product Security