From Brendan.Durkin at defence.gov.au Wed Apr 1 19:20:04 2009 From: Brendan.Durkin at defence.gov.au (Durkin, Brendan MR) Date: Thu, 2 Apr 2009 13:20:04 +1100 Subject: File length limit 1024 [SEC=UNCLASSIFIED] Message-ID: <3C978090D58DA242B29C34C216D67F92043707E3@rusrxm03.drn.mil.au> UNCLASSIFIED Using java.io.File, the maximum path length of a file is 1024 characters, beyond this the File object responds as if the File does not exist. This limitation appears to be OS independant, as I have tested it on both Solaris and Windows XP. Does anyone no if this short comming has been addressed in NIO? Brendan Durkin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20090402/e8ce9039/attachment.html From Alan.Bateman at Sun.COM Thu Apr 2 00:23:49 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 02 Apr 2009 08:23:49 +0100 Subject: File length limit 1024 [SEC=UNCLASSIFIED] In-Reply-To: <3C978090D58DA242B29C34C216D67F92043707E3@rusrxm03.drn.mil.au> References: <3C978090D58DA242B29C34C216D67F92043707E3@rusrxm03.drn.mil.au> Message-ID: <49D46805.5030502@sun.com> Durkin, Brendan MR wrote: > *UNCLASSIFIED* > > Using java.io.File, the maximum path length of a file is 1024 > characters, beyond this the File object responds as if the File does > not exist. > This limitation appears to be OS independant, as I have tested it on > both Solaris and Windows XP. > > > Does anyone no if this short comming has been addressed in NIO? > > > > Brendan Durkin > Both java.io and java.nio.file allow you to access files with paths up to the operating system's limit. By any chance are you thinking about long path support on Windows? This support has been there since jdk6 (and jdk5 update 6). -Alan. From Thomas.Salter at unisys.com Fri Apr 3 07:23:18 2009 From: Thomas.Salter at unisys.com (Salter, Thomas A) Date: Fri, 3 Apr 2009 09:23:18 -0500 Subject: Times in the BasicFileAttributes class Message-ID: I'm curious about the rationale behind representing file times (creationTime, lastAccessTime and lastModifyTime) as long integers with a separate resolution method. Since both Unix and Windows implementations currently return milliseconds, users might mistakenly create a java.util.Date object from the time without considering the units. A bug like this wouldn't be detected until some new file system tried to used alternate units to express the times. 1. Why limit the date range to dates since 1970? This seems to be a Unix-centric view of the world. 2. Why not return a Date or Calendar object for these timestamps? 3. Why does the Windows implementation discard the extra range and precision of Windows file times (100 ns units since 1600)? 4. Is there a method somewhere that takes a long and a TimeUnit parameter and returns a Date or Calendat object? It takes a fair amount of code to handle all the possible TimeUnit values. Tom Salter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20090403/e8b2cc86/attachment.html From Alan.Bateman at Sun.COM Fri Apr 3 08:30:15 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 03 Apr 2009 16:30:15 +0100 Subject: Times in the BasicFileAttributes class In-Reply-To: References: Message-ID: <49D62B87.1010805@sun.com> Salter, Thomas A wrote: > I'm curious about the rationale behind representing file times > (creationTime, lastAccessTime and lastModifyTime) as long integers > with a separate resolution method. > > Since both Unix and Windows implementations currently return > milliseconds, users might mistakenly create a java.util.Date object > from the time without considering the units. A bug like this wouldn't > be detected until some new file system tried to used alternate units > to express the times. > > 1. Why limit the date range to dates since 1970? This seems to be a > Unix-centric view of the world. > 2. Why not return a Date or Calendar object for these timestamps? > 3. Why does the Windows implementation discard the extra range and > precision of Windows file times (100 ns units since 1600)? > 4. Is there a method somewhere that takes a long and a TimeUnit > parameter and returns a Date or Calendat object? It takes a fair > amount of code to handle all the possible TimeUnit values. > > Tom Salter > While many developers will be used to working in milliseconds, file systems and systems APIs have been moving to nanoseconds. We didn't want to define an Instant class that would overlap with the work of the date/time JSR. If that JSR goes into jdk7 then we can re-examine this. The issue with setting values to before 1970 came up on the nio-dev a few weeks ago. It's an API bug and I hope to fix this soon. The awkward issue is that we cannot specify required behavior for cases where an application attempts to set the time to a value that pre-dates the file systems's epoch. Ideally the method should specify that the method fails or specifies that it sets the time to the file system's epoch but these choices are just not feasible to implement in all cases. It's purely an implementation choice that the Windows implementation currently returns the timestamps in milliseconds. It is easily changed to use nanoseconds but we don't have a solution for code that ignores the resolution. As regards conversion - all I can suggest is to use TimeUnit.MILLISECONDS.convert(lastModifiedTime(), resolution()) if you require the value in ms. -Alan. From Thomas.Salter at unisys.com Fri Apr 3 11:00:22 2009 From: Thomas.Salter at unisys.com (Salter, Thomas A) Date: Fri, 3 Apr 2009 13:00:22 -0500 Subject: Times in the BasicFileAttributes class In-Reply-To: <49D62B87.1010805@sun.com> References: <49D62B87.1010805@sun.com> Message-ID: I'd like to encourage you to change the resolution for Windows so that it is not the same as Unix. I suspect most applications get tested on both Windows and some of flavor of Unix/Linux, so if those implementations are different applications will be forced to honor the TimeUnit resolution. -----Original Message----- From: Alan.Bateman at Sun.COM [mailto:Alan.Bateman at Sun.COM] Sent: Friday, April 03, 2009 11:30 AM To: Salter, Thomas A Cc: nio-discuss at openjdk.java.net Subject: Re: Times in the BasicFileAttributes class Salter, Thomas A wrote: > I'm curious about the rationale behind representing file times > (creationTime, lastAccessTime and lastModifyTime) as long integers > with a separate resolution method. > > Since both Unix and Windows implementations currently return > milliseconds, users might mistakenly create a java.util.Date object > from the time without considering the units. A bug like this wouldn't > be detected until some new file system tried to used alternate units > to express the times. > > 1. Why limit the date range to dates since 1970? This seems to be a > Unix-centric view of the world. > 2. Why not return a Date or Calendar object for these timestamps? > 3. Why does the Windows implementation discard the extra range and > precision of Windows file times (100 ns units since 1600)? > 4. Is there a method somewhere that takes a long and a TimeUnit > parameter and returns a Date or Calendat object? It takes a fair > amount of code to handle all the possible TimeUnit values. > > Tom Salter > While many developers will be used to working in milliseconds, file systems and systems APIs have been moving to nanoseconds. We didn't want to define an Instant class that would overlap with the work of the date/time JSR. If that JSR goes into jdk7 then we can re-examine this. The issue with setting values to before 1970 came up on the nio-dev a few weeks ago. It's an API bug and I hope to fix this soon. The awkward issue is that we cannot specify required behavior for cases where an application attempts to set the time to a value that pre-dates the file systems's epoch. Ideally the method should specify that the method fails or specifies that it sets the time to the file system's epoch but these choices are just not feasible to implement in all cases. It's purely an implementation choice that the Windows implementation currently returns the timestamps in milliseconds. It is easily changed to use nanoseconds but we don't have a solution for code that ignores the resolution. As regards conversion - all I can suggest is to use TimeUnit.MILLISECONDS.convert(lastModifiedTime(), resolution()) if you require the value in ms. -Alan. From Thomas.Salter at unisys.com Tue Apr 7 06:18:00 2009 From: Thomas.Salter at unisys.com (Salter, Thomas A) Date: Tue, 7 Apr 2009 08:18:00 -0500 Subject: Glob syntax / Javadoc Message-ID: In the Javadoc for FileSystem.getPathMatcher, the explanations for the /home/* syntaxes explicitly state "on UNIX platforms". Shouldn't these forms match on Windows platforms as well? How else do you write a platform-independent pattern? I'd think the best definition would be to match the name separator character returned by FileSystem.getSeparator(). From Alan.Bateman at Sun.COM Tue Apr 7 08:29:02 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 07 Apr 2009 16:29:02 +0100 Subject: Glob syntax / Javadoc In-Reply-To: References: Message-ID: <49DB713E.9010601@sun.com> Salter, Thomas A wrote: > In the Javadoc for FileSystem.getPathMatcher, the explanations for the /home/* syntaxes explicitly state "on UNIX platforms". Shouldn't these forms match on Windows platforms as well? How else do you write a platform-independent pattern? I'd think the best definition would be to match the name separator character returned by FileSystem.getSeparator(). > The examples you refer are just examples to demonstrate the syntax but yes, the intention in that the separator matches itself. That works well for patterns that are input by the user (say in a command-line tool or file dialog). If code is creating patterns programmatically then it will need to use the separator, eg: String glob = dir.toString() + sep + "*.java"; -Alan. From Jeanfrancois.Arcand at Sun.COM Tue Apr 7 10:14:33 2009 From: Jeanfrancois.Arcand at Sun.COM (Jeanfrancois Arcand) Date: Tue, 07 Apr 2009 13:14:33 -0400 Subject: (ApacheCon EU) Good feedback on NIO.2 Message-ID: <49DB89F9.60700@sun.com> Hi, just sharing...during the week of March 20 I did a talk at ApacheCon EU [1]on NIO.2. The talk was describing the new API (AsyncXX, new File I/O, etc.) and some hints about what I've learned so far having implemented NIO.2 in Project Grizzly and Tomcat 6 (code for Tomcat 6 will soon be proposed to the community). The interesting part about Tomcat is it took me less that 3 hours to port from NIO.1 to NIO.2. The feedback I got was positive and I can say peoples were impress by the new API, specially the new File I/O. Now I can't share the slide has my hard drive die during the flight return and lost it (yes it is ridiculous). Anyway if you are interested, ping me privately and I will share another internal talk I did which is almost similar as the one for ApacheCon, minus the sample code from Tomcat AIO implementation. -- Jeanfrancois [1] http://www.eu.apachecon.com/c/aceu2009/speakers/156 From mthornton at optrak.co.uk Wed Apr 22 02:07:05 2009 From: mthornton at optrak.co.uk (Mark Thornton) Date: Wed, 22 Apr 2009 10:07:05 +0100 Subject: Times in the BasicFileAttributes class In-Reply-To: <49D62B87.1010805@sun.com> References: <49D62B87.1010805@sun.com> Message-ID: <49EEDE39.3090004@optrak.co.uk> Alan Bateman wrote: > Salter, Thomas A wrote: >> I'm curious about the rationale behind representing file times >> (creationTime, lastAccessTime and lastModifyTime) as long integers >> with a separate resolution method. >> Since both Unix and Windows implementations currently return >> milliseconds, users might mistakenly create a java.util.Date object >> from the time without considering the units. A bug like this >> wouldn't be detected until some new file system tried to used >> alternate units to express the times. >> >> 1. Why limit the date range to dates since 1970? This seems to be a >> Unix-centric view of the world. 2. Why not return a Date or Calendar >> object for these timestamps? >> 3. Why does the Windows implementation discard the extra range and >> precision of Windows file times (100 ns units since 1600)? >> 4. Is there a method somewhere that takes a long and a TimeUnit >> parameter and returns a Date or Calendat object? It takes a fair >> amount of code to handle all the possible TimeUnit values. >> >> Tom Salter >> > While many developers will be used to working in milliseconds, file > systems and systems APIs have been moving to nanoseconds. We didn't > want to define an Instant class that would overlap with the work of > the date/time JSR. If that JSR goes into jdk7 then we can re-examine > this. A rather belated response to this, but something I have been thinking about for some time. I think there would be some merit in using a very simple form of Instant that was based internally on the unconverted data from the OS. Thus on Windows it would hold a long value in 100ns units based on 1601. abstract class FileTime implements Comparable, javax.time.InstantProvider { public abstract long getRawValue(); public abstract long toMillis(); public abstract javax.time.Instant toInstant(); // Implement toString to return the ISO8601 format time with all available resolution } The InstantProvider interface and toInstant() method is from JSR310, while toMillis provides compatibility with the existing date/time classes (and alternatives like Joda). In addition provide a FileTimeFactory: abstract class FileTimeFactory { public static FileTimeFactory system(); public abstract long rawResolution(); public abstract long rawEpochMillis(); public abstract FileTime getMinimumValue(); public abstract FileTime getMaximumValue(); public abstract FileTime millisInstant(long millis); public abstract FileTime instant(javax.time.Instant t); public abstract FileTime raw(long rawValue); } Such a scheme would be safer than just returning long values and is easy to make compatible with JSR-310 should it be available. > > The issue with setting values to before 1970 came up on the nio-dev a > few weeks ago. It's an API bug and I hope to fix this soon. The > awkward issue is that we cannot specify required behavior for cases > where an application attempts to set the time to a value that > pre-dates the file systems's epoch. Ideally the method should specify > that the method fails or specifies that it sets the time to the file > system's epoch but these choices are just not feasible to implement in > all cases. The FileTimeFactory suggested above can provide some information on the permitted range of values. Regards, Mark Thornton From Alan.Bateman at Sun.COM Wed Apr 22 04:51:01 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 22 Apr 2009 12:51:01 +0100 Subject: Times in the BasicFileAttributes class In-Reply-To: <49EEDE39.3090004@optrak.co.uk> References: <49D62B87.1010805@sun.com> <49EEDE39.3090004@optrak.co.uk> Message-ID: <49EF04A5.3080507@sun.com> Mark Thornton wrote: > A rather belated response to this, but something I have been thinking > about for some time. I think there would be some merit in using a very > simple form of Instant that was based internally on the unconverted > data from the OS. Thus on Windows it would hold a long value in 100ns > units based on 1601. > > abstract class FileTime implements Comparable, > javax.time.InstantProvider { > public abstract long getRawValue(); > public abstract long toMillis(); > public abstract javax.time.Instant toInstant(); > // Implement toString to return the ISO8601 format time with all > available resolution > } > > The InstantProvider interface and toInstant() method is from JSR310, > while toMillis provides compatibility with the existing date/time > classes (and alternatives like Joda). Thanks for taking time to think about this as it's been hanging around for some time (I'm guilty for putting it on the long finger as I didn't know if JSR-310 was coming or not). An interim solution for a simple Instant-like object seems reasonable (and we later retrofit it to implement InstantProvider if JSR-310 is added) . I'm happy to work with you on a proposal. One initial comment is that we are deliberately using, and adjusting to, the java epoch to avoid adding complexity. Also having FileTime encapsulate the value and resolution is closer to what I have been thinking (so 100ns units would be adjusted to ns to allow it be qualified by a TimeUnit). > In addition provide a FileTimeFactory: > > abstract class FileTimeFactory { > public static FileTimeFactory system(); > public abstract long rawResolution(); > public abstract long rawEpochMillis(); > public abstract FileTime getMinimumValue(); > public abstract FileTime getMaximumValue(); > public abstract FileTime millisInstant(long millis); > public abstract FileTime instant(javax.time.Instant t); > public abstract FileTime raw(long rawValue); > } > > Such a scheme would be safer than just returning long values and is > easy to make compatible with JSR-310 should it be available. >> >> : > The FileTimeFactory suggested above can provide some information on > the permitted range of values. Just on that, I don't think it is feasible for a implementation to know the range. For the default file system at least, the valid range is the intersection of what the operating system supports via its APIs and the range supported by the underlying file system/volume. There are many cases where the latter isn't available/known, particularly with remote file systems. There are cases where we can adjust but many other cases where we cannot. -Alan. From earwin at gmail.com Wed Apr 22 06:52:18 2009 From: earwin at gmail.com (Earwin Burrfoot) Date: Wed, 22 Apr 2009 17:52:18 +0400 Subject: BigBuffer Message-ID: <59b3eb370904220652p46384b30tef0901c67ca8eabc@mail.gmail.com> Alan Bateman wrote: >Rob Butler wrote: >> Hello, >> >> Am I mistaken, or is BigBuffer not actually used anywhere? >> >> Rob >> >> >The changes to support large buffers is not in the repository or javadoc >yet. The integration point in the original draft (which I suspect you >are thinking of) was via methods that provide a view of the big buffer >in terms of the existing Buffer classes. It has been lower priority >compared to the other items on our list. We also need more feedback in >this area from folks needing huge containers outside of the java heap. > >-Alan. Feeding back. Yes, this feature is very important for us. -- Kirill Zakharenko/?????? ????????? (earwin at gmail.com) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785 From leonfin at optonline.net Wed Apr 22 12:21:02 2009 From: leonfin at optonline.net (Leon Finker) Date: Wed, 22 Apr 2009 15:21:02 -0400 Subject: -1 and orderly socket shutdown Message-ID: <001201c9c37f$79bca980$6d35fc80$@net> Is there a reason that result of -1 is used instead of somewhat universal 0 for detecting graceful shutdown on recv side for sockets? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20090422/9645d234/attachment.html From Alan.Bateman at Sun.COM Wed Apr 22 12:55:32 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 22 Apr 2009 20:55:32 +0100 Subject: -1 and orderly socket shutdown In-Reply-To: <001201c9c37f$79bca980$6d35fc80$@net> References: <001201c9c37f$79bca980$6d35fc80$@net> Message-ID: <49EF7634.9050502@sun.com> Leon Finker wrote: > > Is there a reason that result of -1 is used instead of somewhat > universal 0 for detecting graceful shutdown on recv side for sockets? > Thanks! > EOF can't be indicated by 0 as otherwise you couldn't distinguish it from cases where zero bytes are read (say a SocketChannel configured in non-blocking mode). -Alan. From leonfin at optonline.net Wed Apr 22 13:11:03 2009 From: leonfin at optonline.net (Leon Finker) Date: Wed, 22 Apr 2009 16:11:03 -0400 Subject: -1 and orderly socket shutdown In-Reply-To: <49EF7634.9050502@sun.com> References: <001201c9c37f$79bca980$6d35fc80$@net> <49EF7634.9050502@sun.com> Message-ID: <001d01c9c386$7682d710$63888530$@net> I was referring to AsynchronousSocketChannel. But I guess it's to keep it the same as SocketChannel. In AsynchronousSocketChannel one would not get 0 bytes read for tcp, correct? One can get 0 bytes for udp. -----Original Message----- From: Alan.Bateman at Sun.COM [mailto:Alan.Bateman at Sun.COM] Sent: Wednesday, April 22, 2009 3:56 PM To: Leon Finker Cc: nio-discuss at openjdk.java.net Subject: Re: -1 and orderly socket shutdown Leon Finker wrote: > > Is there a reason that result of -1 is used instead of somewhat > universal 0 for detecting graceful shutdown on recv side for sockets? > Thanks! > EOF can't be indicated by 0 as otherwise you couldn't distinguish it from cases where zero bytes are read (say a SocketChannel configured in non-blocking mode). -Alan. From Alan.Bateman at Sun.COM Wed Apr 22 13:20:10 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 22 Apr 2009 21:20:10 +0100 Subject: -1 and orderly socket shutdown In-Reply-To: <001d01c9c386$7682d710$63888530$@net> References: <001201c9c37f$79bca980$6d35fc80$@net> <49EF7634.9050502@sun.com> <001d01c9c386$7682d710$63888530$@net> Message-ID: <49EF7BFA.2030706@sun.com> Leon Finker wrote: > I was referring to AsynchronousSocketChannel. But I guess it's to keep it > the same as SocketChannel. In AsynchronousSocketChannel one would not get 0 > bytes read for tcp, correct? One can get 0 bytes for udp. > If you invoke AsynchronousSocketChannel#read with a buffer that has 0 bytes remaining then it completes immediately with a result of 0 (no I/O operation is initiated). -Alan. From leonfin at optonline.net Wed Apr 22 13:23:10 2009 From: leonfin at optonline.net (Leon Finker) Date: Wed, 22 Apr 2009 16:23:10 -0400 Subject: -1 and orderly socket shutdown In-Reply-To: <49EF7BFA.2030706@sun.com> References: <001201c9c37f$79bca980$6d35fc80$@net> <49EF7634.9050502@sun.com> <001d01c9c386$7682d710$63888530$@net> <49EF7BFA.2030706@sun.com> Message-ID: <001f01c9c388$27cdb110$77691330$@net> Hmm, interesting. Is it ever useful? Maybe it should be treated as error? -----Original Message----- From: Alan.Bateman at Sun.COM [mailto:Alan.Bateman at Sun.COM] Sent: Wednesday, April 22, 2009 4:20 PM To: Leon Finker Cc: nio-discuss at openjdk.java.net Subject: Re: -1 and orderly socket shutdown Leon Finker wrote: > I was referring to AsynchronousSocketChannel. But I guess it's to keep it > the same as SocketChannel. In AsynchronousSocketChannel one would not get 0 > bytes read for tcp, correct? One can get 0 bytes for udp. > If you invoke AsynchronousSocketChannel#read with a buffer that has 0 bytes remaining then it completes immediately with a result of 0 (no I/O operation is initiated). -Alan. From leonfin at optonline.net Fri Apr 24 10:18:29 2009 From: leonfin at optonline.net (Leon Finker) Date: Fri, 24 Apr 2009 13:18:29 -0400 Subject: Question on asynchronous AsynchronousSocketChannel#write Message-ID: <000001c9c500$af9acf00$0ed06d00$@net> Hi, Are there any samples on properly using: AsynchronousSocketChannel#write(ByteBuffer src, A attachment, CompletionHandler handler) ? I'm looking for a best practice example for completed() callback for async write. Can Integer result that is passed to us (in completed callback) be less than the ByteBuffer size that we specified in the write method call? I actually see a case that the result I get in completed callback() for write is bigger than the original ByteBuffer capacity under stress. I'm probably doing something wrong, so I wanted to see a best practice example. I'm on b56. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20090424/6d09f774/attachment.html From Alan.Bateman at Sun.COM Fri Apr 24 10:43:20 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 24 Apr 2009 18:43:20 +0100 Subject: Question on asynchronous AsynchronousSocketChannel#write In-Reply-To: <000001c9c500$af9acf00$0ed06d00$@net> References: <000001c9c500$af9acf00$0ed06d00$@net> Message-ID: <49F1FA38.8010905@sun.com> Leon Finker wrote: > > Hi, > > Are there any samples on properly using: > > AsynchronousSocketChannel#write(ByteBuffer src, A attachment, > CompletionHandler handler) ? > > I?m looking for a best practice example for completed() callback for > async write. Can Integer result that is passed to us (in completed > callback) be less than the ByteBuffer size that we specified in the > write method call? I actually see a case that the result I get in > completed callback() for write is bigger than the original ByteBuffer > capacity under stress. I?m probably doing something wrong, so I wanted > to see a best practice example. I?m on b56. Thank you > We don't have any "best practice" documentation but a good idea to have. The Grizzly repository [1] has a port to this API and may be a useful place to find example code. Short writes are possible (meaning a write may complete having written less than the remaining bytes). You are probably using hasRemaining to check this in the handler and if there are remaining bytes you can initiate another write on the buffer with "this" as the handler. It's hard to say much about the problem you are seeing. A write attempts to write the remaining bytes and it would be a serious overflow bug if it actually wrote more than the buffer's capacity. Are you 100% sure this is really happenin.g? You'll see a number of warnings in the javadoc about ByteBuffers not being safe for use by concurrent threads. Any chance you have a bug where you are using the same buffer for two or more concurrent I/O operations. The implementation defends against changes to the buffer position during I/O operations to prevent attacks but if you are using the same buffer concurrently then you may see strange results. -Alan. [1] https://grizzly.dev.java.net/source/browse/grizzly/ From leonfin at optonline.net Fri Apr 24 11:04:26 2009 From: leonfin at optonline.net (Leon Finker) Date: Fri, 24 Apr 2009 14:04:26 -0400 Subject: Question on asynchronous AsynchronousSocketChannel#write In-Reply-To: <49F1FA38.8010905@sun.com> References: <000001c9c500$af9acf00$0ed06d00$@net> <49F1FA38.8010905@sun.com> Message-ID: <000e01c9c507$1b4f8910$51ee9b30$@net> Thank you. I will look at the example. I'm not 100% sure. I'm positive I'm not using the buffer concurrently. -----Original Message----- From: Alan.Bateman at Sun.COM [mailto:Alan.Bateman at Sun.COM] Sent: Friday, April 24, 2009 1:43 PM To: Leon Finker Cc: nio-discuss at openjdk.java.net Subject: Re: Question on asynchronous AsynchronousSocketChannel#write Leon Finker wrote: > > Hi, > > Are there any samples on properly using: > > AsynchronousSocketChannel#write(ByteBuffer src, A attachment, > CompletionHandler handler) ? > > I'm looking for a best practice example for completed() callback for > async write. Can Integer result that is passed to us (in completed > callback) be less than the ByteBuffer size that we specified in the > write method call? I actually see a case that the result I get in > completed callback() for write is bigger than the original ByteBuffer > capacity under stress. I'm probably doing something wrong, so I wanted > to see a best practice example. I'm on b56. Thank you > We don't have any "best practice" documentation but a good idea to have. The Grizzly repository [1] has a port to this API and may be a useful place to find example code. Short writes are possible (meaning a write may complete having written less than the remaining bytes). You are probably using hasRemaining to check this in the handler and if there are remaining bytes you can initiate another write on the buffer with "this" as the handler. It's hard to say much about the problem you are seeing. A write attempts to write the remaining bytes and it would be a serious overflow bug if it actually wrote more than the buffer's capacity. Are you 100% sure this is really happenin.g? You'll see a number of warnings in the javadoc about ByteBuffers not being safe for use by concurrent threads. Any chance you have a bug where you are using the same buffer for two or more concurrent I/O operations. The implementation defends against changes to the buffer position during I/O operations to prevent attacks but if you are using the same buffer concurrently then you may see strange results. -Alan. [1] https://grizzly.dev.java.net/source/browse/grizzly/ From Alan.Bateman at Sun.COM Mon Apr 27 10:51:46 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 27 Apr 2009 18:51:46 +0100 Subject: Question on asynchronous AsynchronousSocketChannel#write In-Reply-To: <000e01c9c507$1b4f8910$51ee9b30$@net> References: <000001c9c500$af9acf00$0ed06d00$@net> <49F1FA38.8010905@sun.com> <000e01c9c507$1b4f8910$51ee9b30$@net> Message-ID: <49F5F0B2.6060501@sun.com> Leon Finker wrote: > Thank you. I will look at the example. I'm not 100% sure. I'm positive I'm > not using the buffer concurrently. > Thanks for the test case. I've created 6834246 for this and will try to get the fix into b59. This build is reserved for stabilization fixes but this is a good candidate to get approved. -Alan. From marc at petit-huguenin.org Thu Apr 30 11:14:14 2009 From: marc at petit-huguenin.org (Marc Petit-Huguenin) Date: Thu, 30 Apr 2009 11:14:14 -0700 Subject: Selector API [was Re: Java API for SCTP] In-Reply-To: <490C3195.1020909@sun.com> References: <514a207b0810311357u7f81ff9es24b1c842be5025e3@mail.gmail.com> <490C3195.1020909@sun.com> Message-ID: <49F9EA76.6070404@petit-huguenin.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan Bateman wrote: [...] > > As regards non-blocking - yes, it is integrated with the > multiplexing/Selector API. For now the implementation is making use of > an internal API for this. In the medium term we hope to define a > provider-specific API to allow other selectable channel types to > register with the Selector. What are the plans for this API? Thanks. - -- Marc Petit-Huguenin Home: marc at petit-huguenin.org Work: petithug at acm.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkn56nYACgkQ9RoMZyVa61f8DgCeLQhl47hLBF4sMxvkoNhnTxAb SU4An1KESGcFP1vGJUo912RMdZj3dMzh =XtP9 -----END PGP SIGNATURE----- From Alan.Bateman at Sun.COM Thu Apr 30 11:48:07 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 30 Apr 2009 19:48:07 +0100 Subject: Selector API [was Re: Java API for SCTP] In-Reply-To: <49F9EA76.6070404@petit-huguenin.org> References: <514a207b0810311357u7f81ff9es24b1c842be5025e3@mail.gmail.com> <490C3195.1020909@sun.com> <49F9EA76.6070404@petit-huguenin.org> Message-ID: <49F9F267.5040109@sun.com> Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Alan Bateman wrote: > [...] > >> As regards non-blocking - yes, it is integrated with the >> multiplexing/Selector API. For now the implementation is making use of >> an internal API for this. In the medium term we hope to define a >> provider-specific API to allow other selectable channel types to >> register with the Selector. >> > > What are the plans for this API? > The SCTP API is in jdk7 since b56 and as its implementation is in the sun.nio.ch package it means it can use the internal interface to register without requiring a public/supported interface. I would still like to introduce a supported interface to allow other channel implementations integrate, it just hadn't had sufficient priority to bring it to the finish line. So can you say how you would use such an interface? -Alan. From marc at petit-huguenin.org Thu Apr 30 12:02:40 2009 From: marc at petit-huguenin.org (Marc Petit-Huguenin) Date: Thu, 30 Apr 2009 12:02:40 -0700 Subject: Selector API [was Re: Java API for SCTP] In-Reply-To: <49F9F267.5040109@sun.com> References: <514a207b0810311357u7f81ff9es24b1c842be5025e3@mail.gmail.com> <490C3195.1020909@sun.com> <49F9EA76.6070404@petit-huguenin.org> <49F9F267.5040109@sun.com> Message-ID: <49F9F5D0.1070004@petit-huguenin.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan Bateman wrote: > Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Alan Bateman wrote: >> [...] >> >>> As regards non-blocking - yes, it is integrated with the >>> multiplexing/Selector API. For now the implementation is making use of >>> an internal API for this. In the medium term we hope to define a >>> provider-specific API to allow other selectable channel types to >>> register with the Selector. >>> >> >> What are the plans for this API? >> > The SCTP API is in jdk7 since b56 and as its implementation is in the > sun.nio.ch package it means it can use the internal interface to > register without requiring a public/supported interface. I would still > like to introduce a supported interface to allow other channel > implementations integrate, it just hadn't had sufficient priority to > bring it to the finish line. So can you say how you would use such an > interface? I am evaluating the difficulties in implementing a DCCP channel that can register on a selector also used by SCTP, UDP and/or TCP channels. Thanks. - -- Marc Petit-Huguenin Home: marc at petit-huguenin.org Work: petithug at acm.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkn59dAACgkQ9RoMZyVa61cfgACfXFwfwRkOIpejyiKgTbK0Ccyr unEAoKeFjaaHiQ7O6+cl+To11Nf+SfJi =CxkI -----END PGP SIGNATURE-----