Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 27 Feb 2015 06:41:05 +0000 (UTC)
From: "T Jake Luciani (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12771386.1422640739000.31392.1425019265755@Atlassian.JIRA>
In-Reply-To: <JIRA.12771386.1422640739000@Atlassian.JIRA>
References: <JIRA.12771386.1422640739000@Atlassian.JIRA>
 <JIRA.12771386.1422640739588@arcas>
Subject: [jira] [Commented] (CASSANDRA-8709) Convert SequentialWriter from
 using RandomAccessFile to nio channel
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-8709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14339797#comment-14339797 ] 

T Jake Luciani commented on CASSANDRA-8709:
-------------------------------------------

All of your non-direct byte buffer code makes me nervous since you are accessing .array() but I see these are always your own buffers you allocate and never slice so it should be ok...

In particular CompressedSW.flushData() calls crcMetadata.append(compressed.buffer.array(), compressed.buffer.position(), compressed.buffer.limit()) where the last param should be compressed.buffer.remaining().  I don't think this is a real bug since you have called rewind just before so limit() == remaining() in this case. perhaps crcMetadata.append(compressed.buffer.array(), 0, compressed.buffer.limit()) is clearer.

---

In DataIntegrityMetadata, your new appendDirect call shouldn't be using mark and reset since it's racy.  Better to .duplicate() the input buffer.


--

In LZ4Compressor.compress() the source length should be using .remaining() not .limit()


---

Please write a test to write and validate a CompressedSW using all different compressors.


> Convert SequentialWriter from using RandomAccessFile to nio channel
> -------------------------------------------------------------------
>
>                 Key: CASSANDRA-8709
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8709
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Joshua McKenzie
>            Assignee: Joshua McKenzie
>              Labels: Windows
>             Fix For: 3.0
>
>
> For non-mmap'ed I/O on Windows, using nio channels will give us substantially more flexibility w/regards to renaming and moving files around while writing them.  This change in conjunction with CASSANDRA-4050 should allow us to remove the Windows bypass code in SSTableRewriter for non-memory-mapped I/O.
> In general, migrating from instances of RandomAccessFile to nio channels will help make Windows and linux behavior more consistent.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)