From Alan.Bateman at Sun.COM Fri Jun 6 02:09:24 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 06 Jun 2008 10:09:24 +0100 Subject: AsynchronousByteChannel and scatter/gather In-Reply-To: <484880DB.1050608@redhat.com> References: <484880DB.1050608@redhat.com> Message-ID: <4848FEC4.7030102@sun.com> [ moving to nio-discuss (if okay with you) as there are folks interested in this area that don't subscribe to the -dev mailing list ] David M. Lloyd wrote: > I've noticed that AsynchronousByteChannel doesn't support > scatter/gather operations; yet the most of the channels that implement > this interface have scatter/gather operations. Is there any plan to > provide a scatter/gather-capable version of the interface? Or merge > those methods onto the base interface? Only AsynchronousSocketChannel defines scatter/gather operations at this time. A possible candidate to also define these operations in the future is AsynchronousDatagramChannel but there hasn't been sufficient motivation to date. We could add asynchronous variants of the scatter/gather interfaces later if they are needed. > > Also, I see that Pipes do not support the asynchronous operation at > all. Any particular reason? > Pipes can only be used for communication within the same VM. I haven't seen an application that uses more than a handful of them at the same time and I don't expect scalability is an issue. It would be relatively simple to use a thread pool + Pipe's existing channels if someone really needs to combine asynchronous I/O with I/O to pipes (ie: we don't need to add anything to the API to support that). That said, there is some interest in named pipes support for interoperability with native applications and local IPC between VMs on the same machine. This isn't in our scope here but something I have been explored with a view to supporting other protocols in the future. In that case, both SocketChannel and AsynchronousSocketChannel could be used with Unix domain sockets sockets for example. -Alan. From Rajendra.Gutupalli at Sun.COM Fri Jun 6 04:33:21 2008 From: Rajendra.Gutupalli at Sun.COM (Rajendra Gutupalli) Date: Fri, 06 Jun 2008 17:03:21 +0530 Subject: small typo Message-ID: <48492081.7060001@sun.com> Hi Alan, I started looking at NamedAttributeView. I am just trying in Windows XP. I noticed a small typo in method NamedAttributeView#write at " Where there is insufficient spec" (referring Javadoc b91). It supposed to be spelled as "space". Alan, could you please tell me how can I add sub file(named attribute) manually in Windows. I thought what ever name-value attributes I add to the file, should be visible in Properties(Right click + property + summary tab) window of the file. Is that correct? Thanks Rajendra. From Alan.Bateman at Sun.COM Fri Jun 6 05:06:38 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 06 Jun 2008 13:06:38 +0100 Subject: small typo In-Reply-To: <48492081.7060001@sun.com> References: <48492081.7060001@sun.com> Message-ID: <4849284E.5090807@sun.com> Rajendra Gutupalli wrote: > Hi Alan, > > I started looking at NamedAttributeView. I am just trying in Windows XP. > I noticed a small typo in method NamedAttributeView#write at " Where > there is insufficient spec" (referring Javadoc b91). > It supposed to be spelled as "space". Yes, should be "space" - thanks! > Alan, could you please tell me how > can I add sub file(named attribute) manually in Windows. I thought what > ever name-value attributes I add > to the file, should be visible in Properties(Right click + property + > summary tab) window of the file. Is that correct? AFAIK, the "Summary" tab in explorer only reads the contents of data streams that Windows knows about (as it needs to interpret the contents to display them). The usual way to create alternative streams is to append a colon and the stream name to the file name, eg: dir > foo:info will direct the output of the dir command to a data stream named "info" for file foo. If it helps, in the samples directory you'll find a small sample named Xdd that I included to demonstrate this part of the API. In summary: # list foo's named attributes java Xdd foo # set/replace an attribute value java Xdd -set user.mimetype=text/html foo # get an attribute value java Xdd -get user.mimtype foo # delete an attribute java Xdd -del user.mimetype foo You probably know this already but only NTFS supports ADS. I assume you will be testing this on other platforms too. On Linux you'll need to mount the file system with the user_xattr mount option to enable extended attributes. On Solaris then it will work for both ufs and zfz. -Alan. From david.lloyd at redhat.com Fri Jun 6 08:16:23 2008 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 06 Jun 2008 10:16:23 -0500 Subject: AsynchronousByteChannel and scatter/gather In-Reply-To: <4848FEC4.7030102@sun.com> References: <484880DB.1050608@redhat.com> <4848FEC4.7030102@sun.com> Message-ID: <484954C7.60002@redhat.com> On 06/06/2008 04:09 AM, Alan Bateman wrote: > [ moving to nio-discuss (if okay with you) as there are folks interested > in this area that don't subscribe to the -dev mailing list ] > > David M. Lloyd wrote: >> I've noticed that AsynchronousByteChannel doesn't support >> scatter/gather operations; yet the most of the channels that implement >> this interface have scatter/gather operations. Is there any plan to >> provide a scatter/gather-capable version of the interface? Or merge >> those methods onto the base interface? > Only AsynchronousSocketChannel defines scatter/gather operations at this > time. A possible candidate to also define these operations in the future > is AsynchronousDatagramChannel but there hasn't been sufficient > motivation to date. We could add asynchronous variants of the > scatter/gather interfaces later if they are needed. OK. Mostly what I'm driving at is an API issue - why have an interface then for single-buffer asynchronous operations, but not multi-buffer operations? Does the interface add any value to the API? - DML From Alan.Bateman at Sun.COM Fri Jun 6 08:42:16 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 06 Jun 2008 16:42:16 +0100 Subject: AsynchronousByteChannel and scatter/gather In-Reply-To: <484954C7.60002@redhat.com> References: <484880DB.1050608@redhat.com> <4848FEC4.7030102@sun.com> <484954C7.60002@redhat.com> Message-ID: <48495AD8.8010909@sun.com> David M. Lloyd wrote: > : > OK. Mostly what I'm driving at is an API issue - why have an > interface then for single-buffer asynchronous operations, but not > multi-buffer operations? Does the interface add any value to the API? One usage is in the Channels class where interoperability with the streams classes is required. Aside from that I would expect to see AsynchronousByteChannel used by those creating filters or decorating/wrapping a channel. It is an area where we need more feedback to see if other or alternative interfaces are needed. -Alan. From Alan.Bateman at Sun.COM Fri Jun 13 09:55:11 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 13 Jun 2008 17:55:11 +0100 Subject: NIO2 async threading In-Reply-To: <806087.33518.qm@web54008.mail.re2.yahoo.com> References: <806087.33518.qm@web54008.mail.re2.yahoo.com> Message-ID: <4852A66F.10806@sun.com> Rob Butler wrote: > Hello, > > I was wondering how threading would work for asynchronous channels? Since callbacks are invoked to perform all reading/writing that work will always take place in threads controlled by the async provider, right? Is there any standard way to control how many threads are in use? To set the thread type (daemon, non-daemon)? To set the thread names? > > Rob > > > > [ moving to nio-discuss (if okay with you) as there are folks interested in this area that don't subscribe to the -dev mailing list ] The class to check out is AsynchronousChannelGroup. There you will see how to configure the ThreadFactory, number of threads, etc. If you see anything missing or have comments please let us know. -Alan. From david.lloyd at redhat.com Fri Jun 13 11:37:07 2008 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 13 Jun 2008 13:37:07 -0500 Subject: NIO2 async threading In-Reply-To: <4852A66F.10806@sun.com> References: <806087.33518.qm@web54008.mail.re2.yahoo.com> <4852A66F.10806@sun.com> Message-ID: <4852BE53.2030109@redhat.com> On 06/13/2008 11:55 AM, Alan Bateman wrote: > [ moving to nio-discuss (if okay with you) as there are folks interested > in this area that don't subscribe to the -dev mailing list ] > > The class to check out is AsynchronousChannelGroup. There you will see > how to configure the ThreadFactory, number of threads, etc. If you see > anything missing or have comments please let us know. Interesting about the configuration issue mentioned in the javadoc (b91) - is there a link to more information about the Executor discussion? Specifically I'm curious why the implementation needs to know the maximum number of threads. - DML From crodster2k at yahoo.com Fri Jun 13 14:52:17 2008 From: crodster2k at yahoo.com (Rob Butler) Date: Fri, 13 Jun 2008 14:52:17 -0700 (PDT) Subject: BigBuffer Message-ID: <172611.95202.qm@web54009.mail.re2.yahoo.com> Hello, Am I mistaken, or is BigBuffer not actually used anywhere? Rob From crodster2k at yahoo.com Fri Jun 13 15:04:43 2008 From: crodster2k at yahoo.com (Rob Butler) Date: Fri, 13 Jun 2008 15:04:43 -0700 (PDT) Subject: NIO2 async threading Message-ID: <483872.6194.qm@web54009.mail.re2.yahoo.com> ----- Original Message ---- From: Alan Bateman To: Rob Butler Cc: nio-discuss at openjdk.java.net Sent: Friday, June 13, 2008 12:55:11 PM Subject: Re: NIO2 async threading Rob Butler wrote: > Hello, > > I was wondering how threading would work for asynchronous channels? Since callbacks are invoked to perform all reading/writing that work will always take place in threads controlled by the async provider, right? Is there any standard way to control how many threads are in use? To set the thread type (daemon, non-daemon)? To set the thread names? > > Rob > > > > [ moving to nio-discuss (if okay with you) as there are folks interested in this area that don't subscribe to the -dev mailing list ] The class to check out is AsynchronousChannelGroup. There you will see how to configure the ThreadFactory, number of threads, etc. If you see anything missing or have comments please let us know. -Alan. Thanks, that really cleared things up. Jean-Francois has done lots of R&D with NIO. He's found that using temporary selectors and doing IO operations on the same thread (only when waiting briefly for more data to complete a request) leads to higher throughput (and I would suspect lower latency) than using separate 'worker' and 'IO' threads. (http://weblogs.java.net/blog/jfarcand/archive/2006/07/tricks_and_tips_4.html) Such an approach wouldn't be possible with Async NIO, would it? I.E. you get a callback to tell you about new data arrival, but there is no way to hang out (and momentarily block in the callback thread) waiting for more data, is there? If that's the case, while dealing with selectors is a pain, the existing NIO API may ultimately be faster and have lower latency than the NIO2 async API's. Please point out anything I may have missed that would make this not the case. Thanks! Rob From Alan.Bateman at Sun.COM Sat Jun 14 06:39:13 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sat, 14 Jun 2008 14:39:13 +0100 Subject: NIO2 async threading In-Reply-To: <4852BE53.2030109@redhat.com> References: <806087.33518.qm@web54008.mail.re2.yahoo.com> <4852A66F.10806@sun.com> <4852BE53.2030109@redhat.com> Message-ID: <4853CA01.2010103@sun.com> David M. Lloyd wrote: > : > Interesting about the configuration issue mentioned in the javadoc > (b91) - is there a link to more information about the Executor > discussion? Specifically I'm curious why the implementation needs to > know the maximum number of threads. It's not so much the maximum number of threads but rather that an implementation may have a subset of those threads dedicated to handling I/O events and dispatching to completion handlers that consume the result of I/O operations. In that case an application-supplied Executor without additional tuning parameters may not work -- eg: suppose the system supports 64 threads in hardware but the application supplies a thread pool that that has a maximum of 24 threads. As the provider implementation doesn't know anything about the Executor it is given it means it may not be able to determine how many threads it can dedicate to handling I/O events while at the same time allowing the thread pool to handle other tasks needed by the implementation. An application supplied Executor also creates a bunch of uninteresting complications. It may be shutdown at any time by the application, it may have been created with a bounded queue, etc. While the latter issues aren't too interesting there are other thread pool policy issues that can be sensitive to the operating system. For example, on Windows, it is would not be possible to use a thread pool that has keep alive enabled as it could cause random I/O operations to abort when the thread pool is trimmed back. All told, the approach that is currently used eliminates a bunch of issues but has the side effect that the thread pool is not accessible to the application (and so the application can't submit its own tasks - one could argue this is a good thing). That note in red is just a reminder that this isn't cast in stone and we need feedback on its usage. There is also API detail to resolve here as the map of parameters may be error prone. Finally, all this is really just a concern for the more sophisticated applications creating their own channel groups - for simpler usages the default group should provide reasonable defaults. -Alan. From Alan.Bateman at Sun.COM Sat Jun 14 06:39:43 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sat, 14 Jun 2008 14:39:43 +0100 Subject: BigBuffer In-Reply-To: <172611.95202.qm@web54009.mail.re2.yahoo.com> References: <172611.95202.qm@web54009.mail.re2.yahoo.com> Message-ID: <4853CA1F.1020503@sun.com> 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. From Alan.Bateman at Sun.COM Sat Jun 14 07:09:40 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sat, 14 Jun 2008 15:09:40 +0100 Subject: NIO2 async threading In-Reply-To: <483872.6194.qm@web54009.mail.re2.yahoo.com> References: <483872.6194.qm@web54009.mail.re2.yahoo.com> Message-ID: <4853D124.2060206@sun.com> Rob Butler wrote: > : > Thanks, that really cleared things up. > > Jean-Francois has done lots of R&D with NIO. He's found that using temporary selectors and doing IO operations on the same thread (only when waiting briefly for more data to complete a request) leads to higher throughput (and I would suspect lower latency) than using separate 'worker' and 'IO' threads. (http://weblogs.java.net/blog/jfarcand/archive/2006/07/tricks_and_tips_4.html) Such an approach wouldn't be possible with Async NIO, would it? I.E. you get a callback to tell you about new data arrival, but there is no way to hang out (and momentarily block in the callback thread) waiting for more data, is there? > > If that's the case, while dealing with selectors is a pain, the existing NIO API may ultimately be faster and have lower latency than the NIO2 async API's. Please point out anything I may have missed that would make this not the case. > It's probably best not to jump to any conclusions here. The underlying implementations are very different. For the scenario you describe, if a completion handler is consuming the result of a read operation and it initiates another read operation (because its buffer has sufficient remaining space, or due to a short-read) then its handler will execute immediately on the current thread if there is data available (no context switch, no additional latency). There isn't direct support to "bet" on data arriving in a few seconds but as there may be several threads polling events from the kernel then there shouldn't be any delay when the data arrives (note that this is very different to the existing API where a single thread polls with the Selector). Jean-Francois and I talk very regularly. He's on this mailing list and may wish to say something about the work he has done so far to port Grizzly to the new API. I believe there is still work to do so I don't think there is performance numbers to share yet. When he is done perhaps we can get him to write up an equivalent tricks 'n tips for the new API :-) -Alan. From david.lloyd at redhat.com Sat Jun 14 12:58:53 2008 From: david.lloyd at redhat.com (David M. Lloyd) Date: Sat, 14 Jun 2008 14:58:53 -0500 Subject: NIO2 async threading In-Reply-To: <4853CA01.2010103@sun.com> References: <806087.33518.qm@web54008.mail.re2.yahoo.com> <4852A66F.10806@sun.com> <4852BE53.2030109@redhat.com> <4853CA01.2010103@sun.com> Message-ID: <485422FD.6030606@redhat.com> On 06/14/2008 08:39 AM, Alan Bateman wrote: > David M. Lloyd wrote: >> : Interesting about the configuration issue mentioned in the javadoc >> (b91) - is there a link to more information about the Executor >> discussion? Specifically I'm curious why the implementation needs to >> know the maximum number of threads. > It's not so much the maximum number of threads but rather that an > implementation may have a subset of those threads dedicated to handling > I/O events and dispatching to completion handlers that consume the > result of I/O operations. In that case an application-supplied Executor > without additional tuning parameters may not work -- eg: suppose the > system supports 64 threads in hardware but the application supplies a > thread pool that that has a maximum of 24 threads. As the provider > implementation doesn't know anything about the Executor it is given it > means it may not be able to determine how many threads it can dedicate > to handling I/O events while at the same time allowing the thread pool > to handle other tasks needed by the implementation. Ah, but this is the point of Exceutors. The user wants control over the Executor policy because the user knows more than the framework does. If the user wants to devote a 24-thread pool on a 64-core system, that's their business - they have a good reason for it. By duplicating this policy in NIO, we've taken a step backwards - the point of Executors is to *remove* this policy from the frameworks, not to mention taking away a lot of flexibility. > An application supplied Executor also creates a bunch of uninteresting > complications. It may be shutdown at any time by the application, it may > have been created with a bounded queue, etc. While the latter issues > aren't too interesting there are other thread pool policy issues that > can be sensitive to the operating system. For example, on Windows, it is > would not be possible to use a thread pool that has keep alive enabled > as it could cause random I/O operations to abort when the thread pool is > trimmed back. It is a fact of life in the modern Java world that services depend on one another. Java developers by now should have a reasonable expectation that if B depends on A, then A must be started before B, and B must be stopped before A. I don't consider this to be a problem. I don't think it's wise to babysit the user in this regard. Anyone using NIO, will know enough not to do this sort of thing by definition. To paraphrase Stroustrup, this is a technical solution to a social problem. I think it is more reasonable to simply use an Executor and explain the contract in the documentation. The user might have a good reason - testing comes to mind - to use an unusual Executor implementation. Believe me, there's nothing NIO users love doing more than testing. :-) > All told, the approach that is currently used eliminates > a bunch of issues but has the side effect that the thread pool is not > accessible to the application (and so the application can't submit its > own tasks - one could argue this is a good thing). One could argue that on social grounds, yes - not on technical grounds. The current solution solves the social problem, but causes technical limitations - this is a red flag to me. > That note in red is just a reminder that this isn't cast in stone and we need feedback on > its usage. There is also API detail to resolve here as the map of > parameters may be error prone. Finally, all this is really just a > concern for the more sophisticated applications creating their own > channel groups - for simpler usages the default group should provide > reasonable defaults. I hope you consider these points. - DML From Alan.Bateman at Sun.COM Sat Jun 14 14:25:07 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sat, 14 Jun 2008 22:25:07 +0100 Subject: NIO2 async threading In-Reply-To: <485422FD.6030606@redhat.com> References: <806087.33518.qm@web54008.mail.re2.yahoo.com> <4852A66F.10806@sun.com> <4852BE53.2030109@redhat.com> <4853CA01.2010103@sun.com> <485422FD.6030606@redhat.com> Message-ID: <48543733.9050502@sun.com> David M. Lloyd wrote: > : > Ah, but this is the point of Exceutors. The user wants control over the > Executor policy because the user knows more than the framework does. If > the user wants to devote a 24-thread pool on a 64-core system, that's > their > business - they have a good reason for it. By duplicating this policy in > NIO, we've taken a step backwards - the point of Executors is to *remove* > this policy from the frameworks, not to mention taking away a lot of > flexibility. There isn't any intent to duplicate this policy - sorry if it came across that way. At the moment the parameters to construct the Executor are provided by the application when creating the channel group. At the same time the I/O implementation needs some knowledge of the concurrency as it controls the underlying event or completion ports where tasks wait on events. As I said, it's an open point (hence marked in red) where we were looking for feedback so thank you for taking time to consider it. > > : > It is a fact of life in the modern Java world that services depend on > one another. Java developers by now should have a reasonable > expectation that if B depends on A, then A must be started before B, > and B must be stopped before A. I don't consider this to be a problem. > > I don't think it's wise to babysit the user in this regard. Anyone > using NIO, will know enough not to do this sort of thing by > definition. To paraphrase Stroustrup, this is a technical solution to > a social problem. I think it is more reasonable to simply use an > Executor and explain the contract in the documentation. The user > might have a good reason - testing comes to mind - to use an unusual > Executor implementation. Believe me, there's nothing NIO users love > doing more than testing. :-) You'd be amazed by some of the code attached to bug reports :-) As always, it is hard to know how much rope to give the developer. Given that channel groups are intended for sophisticated applications you may be right to ignore these concerns. In the original draft, we had wording on taking care when configuring the thread pool. Alan. From crodster2k at yahoo.com Sun Jun 15 15:04:42 2008 From: crodster2k at yahoo.com (Rob Butler) Date: Sun, 15 Jun 2008 15:04:42 -0700 (PDT) Subject: NIO2 async threading Message-ID: <413920.24291.qm@web54008.mail.re2.yahoo.com> ----- Original Message ---- > From: Alan Bateman > To: Rob Butler > Cc: nio-discuss at openjdk.java.net > Sent: Saturday, June 14, 2008 10:09:40 AM > Subject: Re: NIO2 async threading > > Rob Butler wrote: > > : > > Thanks, that really cleared things up. > > > > Jean-Francois has done lots of R&D with NIO. He's found that using temporary > selectors and doing IO operations on the same thread (only when waiting briefly > for more data to complete a request) leads to higher throughput (and I would > suspect lower latency) than using separate 'worker' and 'IO' threads. > (http://weblogs.java.net/blog/jfarcand/archive/2006/07/tricks_and_tips_4.html) > Such an approach wouldn't be possible with Async NIO, would it? I.E. you get a > callback to tell you about new data arrival, but there is no way to hang out > (and momentarily block in the callback thread) waiting for more data, is there? > > > > If that's the case, while dealing with selectors is a pain, the existing NIO > API may ultimately be faster and have lower latency than the NIO2 async API's. > Please point out anything I may have missed that would make this not the case. > > > It's probably best not to jump to any conclusions here. The underlying > implementations are very different. For the scenario you describe, if a > completion handler is consuming the result of a read operation and it > initiates another read operation (because its buffer has sufficient > remaining space, or due to a short-read) then its handler will execute > immediately on the current thread if there is data available (no context > switch, no additional latency). That should probably be more explicit in the Javadoc. These are the exact kind of threading behaviors people will want more info on. > There isn't direct support to "bet" on > data arriving in a few seconds but as there may be several threads > polling events from the kernel then there shouldn't be any delay when > the data arrives (note that this is very different to the existing API > where a single thread polls with the Selector). Maybe either AsynchronousChannelGroup could have an additional setting, or the read method on AsynchronousSocketChannel could have an additional parameter. This parameter could set the 'wait for more data' delay. If it were on the read method a value of 0 (zero) could be passed if the request was complete, and a non-zero value in milliseconds would be passed to wait for 'more data' before releasing the thread to handle other requests. This might improve performance similar to temporary selectors. Of course some R&D would be necessary to see if it actually was beneficial or not. > Jean-Francois and I talk > very regularly. He's on this mailing list and may wish to say something > about the work he has done so far to port Grizzly to the new API. I > believe there is still work to do so I don't think there is performance > numbers to share yet. When he is done perhaps we can get him to write up > an equivalent tricks 'n tips for the new API :-) That would be great! I've found his research very helpful. From crodster2k at yahoo.com Sun Jun 15 15:09:47 2008 From: crodster2k at yahoo.com (Rob Butler) Date: Sun, 15 Jun 2008 15:09:47 -0700 (PDT) Subject: BigBuffer Message-ID: <170331.55103.qm@web54012.mail.re2.yahoo.com> Is there any need for BigBuffer's in network IO? I could see it's use for MappedByteBuffer's or File IO operations. Rob ----- Original Message ---- > From: Alan Bateman > To: Rob Butler > Cc: nio-discuss at openjdk.java.net > Sent: Saturday, June 14, 2008 9:39:43 AM > Subject: Re: BigBuffer > > 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. From Alan.Bateman at Sun.COM Mon Jun 16 01:16:05 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 16 Jun 2008 09:16:05 +0100 Subject: NIO2 async threading In-Reply-To: <413920.24291.qm@web54008.mail.re2.yahoo.com> References: <413920.24291.qm@web54008.mail.re2.yahoo.com> Message-ID: <48562145.3060602@sun.com> Rob Butler wrote: > : > That should probably be more explicit in the Javadoc. These are the exact kind of threading behaviors people will want more info on. > You're right, it is currently buried and could be moved into its own section. > : > Maybe either AsynchronousChannelGroup could have an additional setting, or the read method on AsynchronousSocketChannel could have an additional parameter. This parameter could set the 'wait for more data' delay. If it were on the read method a value of 0 (zero) could be passed if the request was complete, and a non-zero value in milliseconds would be passed to wait for 'more data' before releasing the thread to handle other requests. This might improve performance similar to temporary selectors. Of course some R&D would be necessary to see if it actually was beneficial or not. > We probably need more feedback and experiences from people using the API before considering anything like this. Jean-Francois can correct me, but I believe his approach is a trade off to avoid the cost of re-registering with the main Selector and re-dispatchinh/handing off to continue the processing for the case that more data arrives within a few seconds. The approach may not carry over as there isn't the equivalent of a Selector that is managed by one thread. -Alan. From crodster2k at yahoo.com Mon Jun 16 12:01:12 2008 From: crodster2k at yahoo.com (Rob Butler) Date: Mon, 16 Jun 2008 12:01:12 -0700 (PDT) Subject: NIO2 async threading Message-ID: <402074.11411.qm@web54010.mail.re2.yahoo.com> > > : > > Maybe either AsynchronousChannelGroup could have an additional setting, or the > read method on AsynchronousSocketChannel could have an additional parameter. > This parameter could set the 'wait for more data' delay. If it were on the read > method a value of 0 (zero) could be passed if the request was complete, and a > non-zero value in milliseconds would be passed to wait for 'more data' before > releasing the thread to handle other requests. This might improve performance > similar to temporary selectors. Of course some R&D would be necessary to see if > it actually was beneficial or not. > > > We probably need more feedback and experiences from people using the API > before considering anything like this. Jean-Francois can correct me, but > I believe his approach is a trade off to avoid the cost of > re-registering with the main Selector and re-dispatchinh/handing off to > continue the processing for the case that more data arrives within a few > seconds. The approach may not carry over as there isn't the equivalent > of a Selector that is managed by one thread. I believe he's looking to avoid the thread context switch, which could be useful in the async API. Using a temporary selector is only an implementation artifact. Rob From Jeanfrancois.Arcand at Sun.COM Tue Jun 17 07:49:04 2008 From: Jeanfrancois.Arcand at Sun.COM (Jeanfrancois Arcand) Date: Tue, 17 Jun 2008 10:49:04 -0400 Subject: NIO2 async threading In-Reply-To: <413920.24291.qm@web54008.mail.re2.yahoo.com> References: <413920.24291.qm@web54008.mail.re2.yahoo.com> Message-ID: <4857CEE0.5000001@sun.com> Salut, Rob Butler wrote: > > ----- Original Message ---- >> From: Alan Bateman >> To: Rob Butler >> Cc: nio-discuss at openjdk.java.net >> Sent: Saturday, June 14, 2008 10:09:40 AM >> Subject: Re: NIO2 async threading >> >> Rob Butler wrote: >>> : >>> Thanks, that really cleared things up. >>> >>> Jean-Francois has done lots of R&D with NIO. He's found that using temporary >> selectors and doing IO operations on the same thread (only when waiting briefly >> for more data to complete a request) leads to higher throughput (and I would >> suspect lower latency) than using separate 'worker' and 'IO' threads. >> (http://weblogs.java.net/blog/jfarcand/archive/2006/07/tricks_and_tips_4.html) >> Such an approach wouldn't be possible with Async NIO, would it? I.E. you get a >> callback to tell you about new data arrival, but there is no way to hang out >> (and momentarily block in the callback thread) waiting for more data, is there? Not sure I fully understand your question, but in Grizzly I've replaced the temporary Selector invocation with: > IoFuture result = > ((AsynchronousSocketChannel)channel).read(byteBuffer); > > try{ > count = result.get(readTimeout, TimeUnit.MILLISECONDS); > } catch (Throwable ex){ > throw new EOFException(ex.getMessage()); > } Now we can get into a case when all threads blocks on the result.get(), which might not perform well. I haven't had a chance to continue my exploration on NIO.2 recently, but soon I will do some performance measure to see what I'm getting. >>> If that's the case, while dealing with selectors is a pain, the existing NIO >> API may ultimately be faster and have lower latency than the NIO2 async API's. >> Please point out anything I may have missed that would make this not the case. >>> >> It's probably best not to jump to any conclusions here. I agree...A good example is under load, a Selector keys list might be becomes very long and optionally cycling that list can be a performance problem. With NIO.2, this list is gone and I suspect we will gain some performance there. The underlying >> implementations are very different. For the scenario you describe, if a >> completion handler is consuming the result of a read operation and it >> initiates another read operation (because its buffer has sufficient >> remaining space, or due to a short-read) then its handler will execute >> immediately on the current thread if there is data available (no context >> switch, no additional latency). > > That should probably be more explicit in the Javadoc. These are the exact kind of threading behaviors people will want more info on. > >> There isn't direct support to "bet" on >> data arriving in a few seconds but as there may be several threads >> polling events from the kernel then there shouldn't be any delay when >> the data arrives (note that this is very different to the existing API >> where a single thread polls with the Selector). > > Maybe either AsynchronousChannelGroup could have an additional setting, or the read method on AsynchronousSocketChannel could have an additional parameter. This parameter could set the 'wait for more data' delay. If it were on the read method a value of 0 (zero) could be passed if the request was complete, and a non-zero value in milliseconds would be passed to wait for 'more data' before releasing the thread to handle other requests. This might improve performance similar to temporary selectors. Of course some R&D would be necessary to see if it actually was beneficial or not. > >> Jean-Francois and I talk >> very regularly. He's on this mailing list and may wish to say something >> about the work he has done so far to port Grizzly to the new API. I >> believe there is still work to do so I don't think there is performance >> numbers to share yet. When he is done perhaps we can get him to write up >> an equivalent tricks 'n tips for the new API :-) > > That would be great! I've found his research very helpful. Thanks! -- Jeanfrancois > > > > From Alan.Bateman at Sun.COM Tue Jun 17 07:56:24 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 17 Jun 2008 15:56:24 +0100 Subject: BigBuffer In-Reply-To: <170331.55103.qm@web54012.mail.re2.yahoo.com> References: <170331.55103.qm@web54012.mail.re2.yahoo.com> Message-ID: <4857D098.3060806@sun.com> Rob Butler wrote: > Is there any need for BigBuffer's in network IO? Not strictly, and it would add clutter. Where needed, the network I/O could be done using a ByteBuffer view into the larger buffer. > I could see it's use for MappedByteBuffer's or File IO operations. > Yes, mapping large files comes up every so often. Sometimes people work around the issue by mapping the file in 2GB chunks; others ask for a contiguous mapping. -Alan. From crodster2k at yahoo.com Tue Jun 17 11:19:04 2008 From: crodster2k at yahoo.com (Rob Butler) Date: Tue, 17 Jun 2008 11:19:04 -0700 (PDT) Subject: BigBuffer Message-ID: <137060.28784.qm@web54005.mail.re2.yahoo.com> > > Rob Butler wrote: > > Is there any need for BigBuffer's in network IO? > Not strictly, and it would add clutter. Where needed, the network I/O > could be done using a ByteBuffer view into the larger buffer. Right, I should have been more clear. I wouldn't want NIO2 to support BigBuffer's for network IO. As you said, it would add clutter and I don't see that there would be any real benefit. From elharo at metalab.unc.edu Fri Jun 27 06:50:41 2008 From: elharo at metalab.unc.edu (Elliotte Harold) Date: Fri, 27 Jun 2008 06:50:41 -0700 Subject: JSR 203 article Message-ID: <4864F031.7000304@metalab.unc.edu> I'm working up an article about the new filesystem API designed for JSR 203 for java.net. It focuses on the most basic pieces: copying and moving files and querying metadata. If anyone would like to take a look at it prior to publication, let me know and I'll send you a link or a draft. -- Elliotte Rusty Harold elharo at metalab.unc.edu Refactoring HTML Just Published! http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA From Alan.Bateman at Sun.COM Fri Jun 27 10:14:34 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 27 Jun 2008 18:14:34 +0100 Subject: JSR 203 article In-Reply-To: <4864F031.7000304@metalab.unc.edu> References: <4864F031.7000304@metalab.unc.edu> Message-ID: <48651FFA.2020800@sun.com> Elliotte Harold wrote: > I'm working up an article about the new filesystem API designed for JSR > 203 for java.net. It focuses on the most basic pieces: copying and > moving files and querying metadata. > > If anyone would like to take a look at it prior to publication, let me > know and I'll send you a link or a draft. > Thanks for the heads-up and for making a preview available. Can you post a link here when it is published? -Alan. From mthornton at optrak.co.uk Fri Jun 27 12:57:13 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Fri, 27 Jun 2008 20:57:13 +0100 Subject: JSR 203 article In-Reply-To: <4864F031.7000304@metalab.unc.edu> References: <4864F031.7000304@metalab.unc.edu> Message-ID: <48654619.8070703@optrak.co.uk> Elliotte Harold wrote: > I'm working up an article about the new filesystem API designed for JSR > 203 for java.net. It focuses on the most basic pieces: copying and > moving files and querying metadata. > > If anyone would like to take a look at it prior to publication, let me > know and I'll send you a link or a draft. > I hope you also mention a few fixes to flaws in the existing io support. Path.delete() is rather more informative when it fails than the old File.delete() method. For example, if the file is open I get this java.nio.file.FileSystemException: C:\Users\MTHORN~2\AppData\Local\Temp\chk8666.tmp: The process cannot access the file because it is being used by another process. The Path resolve and relativize methods are other simple but welcome additions. Mark Thornton From mthornton at optrak.co.uk Fri Jun 27 13:11:25 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Fri, 27 Jun 2008 21:11:25 +0100 Subject: MIME Types Message-ID: <4865496D.50507@optrak.co.uk> The Files.probeContentType documentation includes this sentence: "The string is guaranteed to be parsable according to the grammar in the RFC". However, one of the values I get is "image/OLYMPUS Raw Format" --- the RFC doesn't allow spaces in the sub type. Of course this also neither an IANA registered type nor does it start with x-. My registry entry for orf is "image/OLYMPUS Raw Format", so it is difficult to return anything else, but it does mean the guarantee can't be maintained. Another illegal MIME type "app/gg" app isn't a legal type (example: Documents\My Google Gadgets\Analog Clock-Google.gg) Mark Thornton From Rajendra.Gutupalli at Sun.COM Mon Jun 30 04:37:58 2008 From: Rajendra.Gutupalli at Sun.COM (Rajendra Gutupalli) Date: Mon, 30 Jun 2008 17:07:58 +0530 Subject: MIME Types In-Reply-To: <4865496D.50507@optrak.co.uk> References: <4865496D.50507@optrak.co.uk> Message-ID: <4868C596.4050605@Sun.Com> Mark Thornton wrote: > The Files.probeContentType documentation includes this sentence: "The > string is guaranteed to be parsable according to the grammar in the > RFC". However, one of the values I get is "image/OLYMPUS Raw Format" > --- the RFC doesn't allow spaces in the sub type. Of course this also > neither an IANA registered type nor does it start with x-. My registry > entry for orf is "image/OLYMPUS Raw Format", so it is difficult to > return anything else, but it does mean the guarantee can't be maintained. > > Another illegal MIME type > "app/gg" app isn't a legal type (example: Documents\My Google > Gadgets\Analog Clock-Google.gg) Hi Mark, I tried to see whether I can reproduce this behavior in my Ubuntu (GNOME Desktop) machine. I created a mime type "application/rajendra gutupalli" which contains a space in sub type and able to get this mime type using Path.probeContentType(). This mime type should have been filtered by the implementation. Steps to be followed to create mime type in Ubuntu. > created mime type file raj.xml file in the /usr/share/mime/packages/ directory Word document >update mime database with the following command. rajendra at client24: sudo update-mime-database /usr/share/mime >Files.probeContentType() returns the following string. application/rajendra gutupalli we will get to know exact behavior for this scenario once Alan is back to work. Thanks Rajendra.