Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Filechannel  RSS feed

 
vidya sagar
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here is my requirement

I want to read a remote file using FTP Connection and write into local system.I want to read as blocks using FileChannel rather than reading as bytes from the outputStream.

Whether it is possible to do so?.Can any throw some lights how to proceed further?
 
Joe Ess
Bartender
Posts: 9429
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That depends on your "FTP Connection" using and exposing a Channel. What are you using for FTP?
Any particular reason you want a FileChannel in the first place?
 
vidya sagar
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For FTP Connection i am using



As per my boss, rather using bufferedInputStream he wants to have FileChannel over here???is it possible to have like that???
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe your boss likes doing micro-management? Why would he even care?

As an aside, I'd recommend using a proper FTP client like Jakarta Commons Net instead of rolling your own in that way. If for no other reason that sooner or later you'll need to switch directories or do some other FTP-specific task.
 
Joe Ess
Bartender
Posts: 9429
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by vidya sagar:

As per my boss, rather using bufferedInputStream he wants to have FileChannel over here???is it possible to have like that???


No. openConnection only gives you an InputStream, so you can't get at the underlaying channel.
Is there any particular reason your boss wants to use a channel? My guess is that he heard that NIO is "better" than java.io streams. Tell him that under the covers, java.io is implemented using channels (hence the getChannel method in File*putStream) so the performance difference is negligible*. NIO introduced new functionality which, if needed, give good reason to use NIO. If you don't need the new functionality, you don't need NIO*.
*speaking in broad terms, of course.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Joe Ess]: Tell him that under the covers, java.io is implemented using channels (hence the getChannel method in File*putStream) so the performance difference is negligible*

True in general. But one of the bigger wins you can (often but not always) get from NIO is in copying to or from a file using FileChannel's transferFrom() or transferTo(). That may be what motivated the boss here.

[Joe Ess]: No. openConnection only gives you an InputStream, so you can't get at the underlaying channel.

You can't get at an underlying channel, but you can use Channels.newChannel() to create a wrapping channel:

Note that this assumes the server will set the content length of the file correctly. If not... well there are other ways to transfer data with channels, reading into a ByteBuffer etc, but they're slower and more work to figure out, so try this first.

Unfortunately I suspect this won't really result in much (or any) improvement in speed. The benefits you get from transferFrom() or transferTo(), when you do get them, are from the implementation's ability to delegate most of the work to hardware. If you transfer from a FileChannel to another FileChannel, your OS will probably just tell the hard drive what to do, and the hard drive will just transfer bytes from one location to another without bothering to transfer any of them into memory along the way so that the JVM can look at them. The JVM involvement is minimal, and no time needs to be spent copying data into a byte[] array, or out of one.

But when we use URLConnection's InputStream, we lose that benefit. The data has already been transferred into memory and into the JVM, and now you essentially have to transfer it out again by writing to a FileOutputStream or FileChannel. So while using Channels.newChannel() may satisfy the literal requirements of doing what your boss has asked for, it may not really help performance much.

If there's a Java FTP client out there that exposes a ReadableByteChannel to the user, that might be beneficial. Offhand I don't know of one, but there may be one somewhere. Or you could download the source to Jakarta Commons Net and modify their FTPClient to expose a SocketChannel for use.

If your boss really wants you to spend time on this, it's possible. There's no guarantee however that it will result in substantial performance benefits. Especially on a client - chances are good that what you're really waiting for is either the server or the network, outside your control. So don't spend a lot of time on this simply assuming that using NIO will solve your performance problems. It may not. Your boss needs to understand that it's a gamble, and probably not worth trying unless the current performance problems are really significant. Good luck.
 
vidya sagar
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks to Joe Ess,Ulf,Jim for spending valuable time over here.

I make some modifications over Jim code and show working code to my boss and now he is very happy to have using Filechannel for FTP.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16028
87
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by vidya sagar:
I make some modifications over Jim code and show working code to my boss and now he is very happy to have using Filechannel for FTP.

That's fine, but does your boss also realize that this does not make your code any faster or any more efficient and that his requirement was based on an invalid assumption? :roll:
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!