Hi,
I filed a ticket on this problem.
https://issues.apache.org/jira/browse/CASSANDRA-2297
Thanks
Muga Nishizawa,
On Sat, Mar 5, 2011 at 6:10 AM, Jonathan Ellis wrote:
> Can you open a ticket with the exception you saw?
>
> On Fri, Mar 4, 2011 at 2:51 PM, Terje Marthinussen
> wrote:
>> Ah, yes
Can you open a ticket with the exception you saw?
On Fri, Mar 4, 2011 at 2:51 PM, Terje Marthinussen
wrote:
> Ah, yes, I should have noticed that distinction.
> We actually hit this overflow on a row that was more than 60GB (yes, we had
> to count the number of digits a few times to make sure).
>
Ah, yes, I should have noticed that distinction.
We actually hit this overflow on a row that was more than 60GB (yes, we had
to count the number of digits a few times to make sure).
On Sat, Mar 5, 2011 at 5:41 AM, Jonathan Ellis wrote:
> Second try:
>
> - this isn't used in row size (which is n
Second try:
- this isn't used in row size (which is not limited to 2GB)
- it's used both for the column index summary and index-block reading,
both of which should be well under 2GB
- however, I don't see any technical reason this method should return
an int instead of a long
- if we make that cha
You're right, I was looking at the no-arg bytesPastMark overload. Sorry!
On Fri, Mar 4, 2011 at 2:32 PM, Terje Marthinussen
wrote:
> Are you entirely sure?
> My Eclipse disagree and the Exception we had a day ago in a 0.7.3 install
> disagree too :)
>
> Terje
>
> On Sat, Mar 5, 2011 at 5:01 AM,
That method is unused, so it's a little academic.
On Fri, Mar 4, 2011 at 1:36 PM, Terje Marthinussen
wrote:
> Hi,
>
> Any good reason this guy
> public int bytesPastMark(FileMark mark)
> {
> assert mark instanceof BufferedRandomAccessFileMark;
> long bytes = getFilePointer() - (
