wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes File Channels == Big Headache Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "File Channels == Big Headache" Watch "File Channels == Big Headache" New topic
Author

File Channels == Big Headache

Rob Zidsen
Greenhorn

Joined: Jul 07, 2003
Posts: 16
A note to those unfamiliar with NIO and thinking of using it: Stay away from these things! They've caused me so much headache over the last couple of days. Stick with RandomAccessFiles. I swear, I use the exact same code in some places and sometimes it works, sometimes it doesn't. It's unreliable. It's maddening. I'd be so much further along now if I hadn't tried to incorporate these things.
I've never had these problems using RandomAccessFiles. Sure, it's a bit slower, but who cares. Stick with what works. Save yourselves the headaches.
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
Rob, I'm suprised to hear you say that. What are you having trouble with? maybe I can help?
M
[ August 15, 2003: Message edited by: Max Habibi ]

Java Regular Expressions
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Well, unless you want to learn about them for your own benefit. Which I do recommend. But it depends on your goals and time frame - NIO does have a bit of a learning curve; it's not as familiar as one might hope. Once you figure it out, the final code can be fairly simple - it's getting there that can be less than straightforward. Then again, it's not nearly as bad as, say, getting table columns to work correctly. :roll: IMO anyway.
[ August 15, 2003: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Rob Zidsen
Greenhorn

Joined: Jul 07, 2003
Posts: 16
Hello Max,
I'm just having trouble with the read/write operations sometimes. It seems to work in some places, but in other places it doesn't work. I've tried moving where I created the byte buffer, etc. to geti t to produce the results I want, and sometimes that works, too. Although to be honest that makes me even more concerned.
Here's a snippet of the code that works in most places but isn't working in create():

here's my Random Access File substitution:
Tony Collins
Ranch Hand

Joined: Jul 03, 2003
Posts: 435
When you write to a file channel the position is moved on by the amount of bytes written. So I think you're moving your position twice(implicitlly and explicitly).
Tony
Tony Collins
Ranch Hand

Joined: Jul 03, 2003
Posts: 435
Originally posted by Tony Collins:
When you write to a file channel the position is moved on by the amount of bytes written. So you might be moving your position twice(implicitlly and explicitly). i.e you supply an offset to your FileChannel that has already been moved on.
Tony
Rob Zidsen
Greenhorn

Joined: Jul 07, 2003
Posts: 16
Tony, why should I care where the FileChannel is pointing? I'm not reading/writing relative to it's current position. I'm using an absolute file position to write the data.
Tony Collins
Ranch Hand

Joined: Jul 03, 2003
Posts: 435
Yeah I can see that now.
Are you testing this with multiple threads, as I believe only writing ByteBuffer is atomic. So the move and write method is not atomic.
I moved to the position required and used write(ByteBuffer[]) to atomically write the whole record and that worked fine. The record is locked so it can't be updated by anything else and dirty reads are avoided as the wrte is atomic
[ August 18, 2003: Message edited by: Tony Collins ]
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Rob, are you reusing that validFlagBuf? If so, you probably need to clear() it after each write().
Also, is your strRecord padded out with spaces or something to ensure it occupies the full record length? If not, then you may still have part of the old record immediately after what you just wrote - the record format wouldn't have any way of telling where the intended end of the record was, so the two would just run together. So make sure there are spaces, or at least one null, at the end of each record.
Tony Collins
Ranch Hand

Joined: Jul 03, 2003
Posts: 435
Yeah or after you write to the bytebuffer rewind to the start of it, before you use it.
Rob Zidsen
Greenhorn

Joined: Jul 07, 2003
Posts: 16
thanks for your help guys. that's the problem I guess. I didn't reset the buffer position to 0.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: File Channels == Big Headache