Re: Possible issue with read repair?

2012-10-11 Thread Niklas Ekström 

Thanks!


2012-10-11 16:55, Jonathan Ellis skrev:

https://issues.apache.org/jira/browse/CASSANDRA-4792

On Wed, Oct 10, 2012 at 4:30 PM, Jonathan Ellis  wrote:

You're both right -- "read repair" as a concept is indeed performed
asynchronously, but RowRepairResolver is used for synchronous, high-CL
reads as well, which is the code Niklas is referring to.

Niklas, can you create a ticket to fix this officially?

On Wed, Oct 10, 2012 at 3:31 PM, Mikhail Panchenko  wrote:

I'll take a stab:

Without looking at the code, that seems perfectly fine - the purpose of
read repair is to repair potentially stale data out of band. It is
acceptable (from the viewpoint of the datastore) to have "stale" reads
while read-repair happens in the background. Once the repair is completed,
future reads will have the correct data ("eventually"). Reads do not and
should not block on read repair tasks. See
http://www.datastax.com/docs/1.1/cluster_architecture/about_client_requests#about-read-requestsfor
more info.

In order to achieve what you're looking for and eliminate the window you
are describing, one would write and read at QUORUM consistency level.

On Wed, Oct 10, 2012 at 1:25 PM, Niklas Ekström  wrote:


Hi,

I’m looking in the file StorageProxy.java (Cassandra 1.1.5), and line 766
seems odd to me.

FBUtilities.waitOnFutures() is called with the repairResults from the
RowRepairResolver resolver.

The problem though is that repairResults is only assigned when the object
is created at line 737 in StorageProxy.java, and there it is assigned to
Collections.emptyList(), and in the resolve() method in RowRepairResolver,
which is indirectly called from line 771 in StorageProxy.java, that is,
after the call to FBUtilities.waitOnFutures().

So the effect is that line 766 in StorageProxy.java is essentially a no-op.

If on the other hand line 766 is moved down to just below the try-catch
block under it (to line 777), the effect of the call to
FBUtilities.waitOnFutures() would be to wait for responses to the
READ_REPAIR message. Not waiting for responses to read repair messages
opens a window of time in which stale reads can happen.

Does this sound reasonable or am I overlooking something?

Regards,
Niklas




--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com

Possible issue with read repair?

2012-10-10 Thread Niklas Ekström 
Hi,

I’m looking in the file StorageProxy.java (Cassandra 1.1.5), and line 766 seems 
odd to me.

FBUtilities.waitOnFutures() is called with the repairResults from the 
RowRepairResolver resolver.

The problem though is that repairResults is only assigned when the object is 
created at line 737 in StorageProxy.java, and there it is assigned to 
Collections.emptyList(), and in the resolve() method in RowRepairResolver, 
which is indirectly called from line 771 in StorageProxy.java, that is, after 
the call to FBUtilities.waitOnFutures().

So the effect is that line 766 in StorageProxy.java is essentially a no-op.

If on the other hand line 766 is moved down to just below the try-catch block 
under it (to line 777), the effect of the call to FBUtilities.waitOnFutures() 
would be to wait for responses to the READ_REPAIR message. Not waiting for 
responses to read repair messages opens a window of time in which stale reads 
can happen.

Does this sound reasonable or am I overlooking something?

Regards,
Niklas

Possible issue with read repair?

2012-10-10 Thread Niklas Ekström 
Hi,

I’m looking in the file StorageProxy.java (Cassandra 1.1.5), and line 766 seems 
odd to me.

FBUtilities.waitOnFutures() is called with the repairResults from the 
RowRepairResolver resolver.

The problem though is that repairResults is only assigned when the object is 
created at line 737 in StorageProxy.java, and there it is assigned to 
Collections.emptyList(), and in the resolve() method in RowRepairResolver, 
which is indirectly called from line 771 in StorageProxy.java, that is, after 
the call to FBUtilities.waitOnFutures().

So the effect is that line 766 in StorageProxy.java is essentially a no-op.

If on the other hand line 766 is moved down to just below the try-catch block 
under it (to line 777), the effect of the call to FBUtilities.waitOnFutures() 
would be to wait for responses to the READ_REPAIR message. Not waiting for 
responses to read repair messages opens a window of time in which stale reads 
can happen.

Does this sound reasonable or am I overlooking something?

Regards,
Niklas

Re: Build failed in Jenkins: Cassandra-quick #489

2012-05-22 Thread Niklas Ekström 
Hi,

Is there any way to stop receiving mail from Apache Jenkins Server
without unsubscribing from the Cassandra dev mailing list?

/Niklas

On mån, 2012-05-21 at 17:25 +, Apache Jenkins Server wrote:
> See 
> 
> Changes:
> 
> [jbellis] synchronize LCS getEstimatedTasks to avoid CME
> 
> [jbellis] edit CHANGES
> 
> --
> [...truncated 411 lines...]
> [junit] 
> [junit] Testsuite: org.apache.cassandra.dht.RangeTest
> [junit] Tests run: 22, Failures: 0, Errors: 0, Time elapsed: 0.676 sec
> [junit] 
> [junit] Testsuite: org.apache.cassandra.gms.ArrivalWindowTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.63 sec
> [junit] 
> [junit] Testsuite: org.apache.cassandra.gms.GossipDigestTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.058 sec
> [junit] 
> [junit] Testsuite: org.apache.cassandra.gms.SerializationsTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 15.058 sec
> [junit] 
> [junit] Testsuite: org.apache.cassandra.hadoop.ColumnFamilyInputFormatTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.244 sec
> [junit] 
> [junit] Testsuite: org.apache.cassandra.io.BloomFilterTrackerTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 14.176 sec
> [junit] 
> [junit] Testsuite: org.apache.cassandra.io.CompactSerializerTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 16.141 sec
> [junit] 
> [junit] Testsuite: org.apache.cassandra.io.LazilyCompactedRowTest
> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 34.056 sec
> [junit] 
> [junit] Testsuite: 
> org.apache.cassandra.io.compress.CompressedRandomAccessReaderTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.443 sec
> [junit] 
> [junit] - Standard Error -
> [junit]  WARN 17:17:26,848 open(null, O_RDONLY) failed, errno (14).
> [junit] -  ---
> [junit] Testsuite: org.apache.cassandra.io.sstable.DescriptorTest
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.06 sec
> [junit] 
> [junit] Testsuite: org.apache.cassandra.io.sstable.IndexHelperTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.06 sec
> [junit] 
> [junit] Testsuite: org.apache.cassandra.io.sstable.LegacySSTableTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 13.155 sec
> [junit] 
> [junit] Testsuite: 
> org.apache.cassandra.io.sstable.SSTableMetadataSerializerTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.137 sec
> [junit] 
> [junit] Testsuite: org.apache.cassandra.io.sstable.SSTableReaderTest
> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 18.034 sec
> [junit] 
> [junit] Testsuite: org.apache.cassandra.io.sstable.SSTableSimpleWriterTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 12.785 sec
> [junit] 
> [junit] Testsuite: org.apache.cassandra.io.sstable.SSTableTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 13.223 sec
> [junit] 
> [junit] Testsuite: 
> org.apache.cassandra.io.util.BufferedRandomAccessFileTest
> [junit] Tests run: 18, Failures: 0, Errors: 0, Time elapsed: 2.509 sec
> [junit] 
> [junit] Testsuite: org.apache.cassandra.locator.DynamicEndpointSnitchTest
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.951 sec
> [junit] 
> [junit] Testsuite: org.apache.cassandra.locator.EC2SnitchTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.641 sec
> [junit] 
> [junit] Testsuite: 
> org.apache.cassandra.locator.NetworkTopologyStrategyTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.656 sec
> [junit] 
> [junit] Testsuite: 
> org.apache.cassandra.locator.OldNetworkTopologyStrategyTest
> [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 12.18 sec
> [junit] 
> [junit] - Standard Output ---
> [junit] toStream : [(158873535527910577765226390751398592512,0], 
> (0,34028236692093846346337460743176821145]]
> [junit] toFetch : 
> [(127605887595351923798765477786913079296,148873535527910577765226390751398592512]]
> [junit] toStreamExpected : [(158873535527910577765226390751398592512,0], 
> (0,34028236692093846346337460743176821145]]
> [junit] toFetchExpected : 
> [(127605887595351923798765477786913079296,148873535527910577765226390751398592512]]
> [junit] -  ---
> [junit] Testsuite: 
> org.apache.cassandra.locator.ReplicationStrategyEndpointCacheTest
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 12.388 sec
> [junit] 
> [junit] Testsuite: org.apache.cass

Re: Consistency with Sequential Mutation/Access?

2012-04-24 Thread Niklas Ekström 
On tis, 2012-04-24 at 20:08 +0530, Praveen Baratam wrote:
> I will start with a hypothetical scenario to make my question easy to
> comprehend.
> 
> Time 1: Client A updates Row 1 in CF C. N=3, W=1
> 
> Time 2: Client A reads Row1 in CF C. N=3, R=1
> 
> Can we expect the update to be seen by all replicas and reply consistently
> in T2?
> 
> I presume Cassandra queues job messages on each node for execution. And
> because the coordinator node sends write messages to all replicas
> irrespective of how many replicas it  waits for ACK,

But there is no guarantee that all replicas receives the write messages
just because the messages were sent. Perhaps at T1 there was a (long
lasting) network partition and only the replica that responded with an
ACK actually got the message. Then at T2 the network partition may have
healed and the replica that ACK'ed the write may have crashed.

> the READ Job will be
> executed on each replica after the WRITE job, essentially delivering
> consistent data on sequential access.
> 
> Is this the way or there is no order in which messages are received and
> processed?

Niklas