[Cassandra Wiki] Trivial Update of "Ethan73G" by Ethan73G
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "Ethan73G" page has been changed by Ethan73G: http://wiki.apache.org/cassandra/Ethan73G New page: Hi !! I am ELLA MOSS. I am from Deltona. I am 54.<> I might join The Angry Military School in Pasadena. My father name is Erik and he is a Pilot. My mummy is a Broker.<> <> Here is my weblog; [[http://www.blindchildrenscenter.org/cheapbeatsheadphones.html|beats earphones]]
[Cassandra Wiki] Trivial Update of "BrandyOPT" by BrandyOPT
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "BrandyOPT" page has been changed by BrandyOPT: http://wiki.apache.org/cassandra/BrandyOPT New page: Hi !! The name is BUFFY MORROW. I live in Des Moines.<> <> This march i will be 36. I and my sister go to The Free Prep School of Light-Hearted People built at Belfast. I also like to Scale Models. My dad name is Douglas and he is a Fowler. My mother is a Waiter.<> <> Feel free to visit my page; [[http://louisvuittonhandbagoutlets.blinkweb.com|louis vuitton outlet online]]
[Cassandra Wiki] Trivial Update of "EllenBeat" by EllenBeat
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "EllenBeat" page has been changed by EllenBeat: http://wiki.apache.org/cassandra/EllenBeat New page: I am staying at Topeka. My age is 58. I want to study at The Lucky Prep School of Crammed People located in Monroe.<> <> I have a job as Wood-cutter. My father name is Steve and he is a Poet. My momy is a Race driver.<> <> Look at my web page :: [[http://www.majorguccioutlet.com|gucci belt]]
[Cassandra Wiki] Trivial Update of "MaxineVVY" by MaxineVVY
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "MaxineVVY" page has been changed by MaxineVVY: http://wiki.apache.org/cassandra/MaxineVVY New page: Soon i will turn 46. I might take night schooling in The Reliable School of Neat Education situated in Little Rock.<> I have a job as Coachman. I am a fan of Book Making. My dad name is Ross and he is a Obstetrician. My momy is a Disc jockey.<> <> My webpage ... [[http://louisvuittonhandbagoutlets.blinkweb.com|louis vuitton online]]
[jira] [Created] (CASSANDRA-5279) Provide a nodetool command to close stream sessions
Ahmed Bashir created CASSANDRA-5279: --- Summary: Provide a nodetool command to close stream sessions Key: CASSANDRA-5279 URL: https://issues.apache.org/jira/browse/CASSANDRA-5279 Project: Cassandra Issue Type: Improvement Components: Core, Tools Affects Versions: 1.1.9 Reporter: Ahmed Bashir It would be quite useful to be able to close stream sessions (derived from AbstractStreamSession) via nodetool. This could be done in total or by session ID (all stream sessions have an ID). Stream sessions can be long-running, cause load on the network, send a very large amount of data to endpoints, and trigger large amount of pending compaction tasks. Just like we make it possible to cancel compaction, it is very useful to be able to close these sessions via nodetool (close() is if such sessions are affecting cluster stability (which they can) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "ChastityM" by ChastityM
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "ChastityM" page has been changed by ChastityM: http://wiki.apache.org/cassandra/ChastityM New page: Hey guys !! The name is HIEN MATHIS. I am 36. My parents want me to join The Fresh Boarding School located in San Francisco.<> I am planning to become a Confectioner.<> <> my site ... [[http://louis-vuittonhandbags.blinkweb.com|louis vuitton usa]]
[jira] [Comment Edited] (CASSANDRA-2699) continuous incremental anti-entropy
[
https://issues.apache.org/jira/browse/CASSANDRA-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583453#comment-13583453
]
Benjamin Coverston edited comment on CASSANDRA-2699 at 2/21/13 7:19 PM:
>From CASSANDRA-4482
{quote}
Instead, we maintain a Merkle Tree (MT) in memory and update it with every
single column insert in ColumnFamilyStore.apply(). We use
column.updateDigest(digest) on all the changes in order to create a hash per
column update and then XOR this hash with the existing one in the Merkle Tree
bucket for the corresponding row.
This Merkle Tree is created with the column family (one per range), initialized
with zeros, and persisted to disk with regular snapshots.
The commutative properties of XOR make it possible to update the MT
incrementally without having to read on write.
{quote}
I'm pretty sure this means that we should be able to XOR the buckets together
from pre-computed merkle tree SSTable components.
We could just create these on flush, merge them on compaction, then validation
compaction is just a read of MT components and merge.
was (Author: bcoverston):
From CASSANDRA-4482
{quote}
Instead, we maintain a Merkle Tree (MT) in memory and update it with every
single column insert in ColumnFamilyStore.apply(). We use
column.updateDigest(digest) on all the changes in order to create a hash per
column update and then XOR this hash with the existing one in the Merkle Tree
bucket for the corresponding row.
This Merkle Tree is created with the column family (one per range), initialized
with zeros, and persisted to disk with regular snapshots.
The commutative properties of XOR make it possible to update the MT
incrementally without having to read on write.
{quote}
I'm pretty sure this means that we should be able to XOR the buckets together
from pre-computed merkle tree SSTable components.
We could just create these on flush, merge them on compaction, then validation
compaction is just a read, MT components and merge.
> continuous incremental anti-entropy
> ---
>
> Key: CASSANDRA-2699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2699
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Peter Schuller
>Assignee: Peter Schuller
>
> Currently, repair works by periodically running "bulk" jobs that (1)
> performs a validating compaction building up an in-memory merkle tree,
> and (2) streaming ring segments as needed according to differences
> indicated by the merkle tree.
> There are some disadvantages to this approach:
> * There is a trade-off between memory usage and the precision of the
> merkle tree. Less precision means more data streamed relative to
> what is strictly required.
> * Repair is a periodic "bulk" process that runs for a significant
> period and, although possibly rate limited as compaction (if 0.8 or
> backported throttling patch applied), is a divergence in terms of
> performance characteristics from "normal" operation of the cluster.
> * The impact of imprecision can be huge on a workload dominated by I/O
> and with cache locality being critical, since you will suddenly
> transfers lots of data to the target node.
> I propose a more incremental process whereby anti-entropy is
> incremental and continuous over time. In order to avoid being
> seek-bound one still wants to do work in some form of bursty fashion,
> but the amount of data processed at a time could be sufficiently small
> that the impact on the cluster feels a lot more continuous, and that
> the page cache allows us to avoid re-reading differing data twice.
> Consider a process whereby a node is constantly performing a per-CF
> repair operation for each CF. The current state of the repair process
> is defined by:
> * A starting timestamp of the current iteration through the token
> range the node is responsible for.
> * A "finger" indicating the current position along the token ring to
> which iteration has completed.
> This information, other than being in-memory, could periodically (every
> few minutes or something) be stored persistently on disk.
> The finger advances by the node selecting the next small "bit" of the
> ring and doing whatever merkling/hashing/checksumming is necessary on
> that small part, and then asking neighbors to do the same, and
> arranging for neighbors to send the node data for mismatching
> ranges. The data would be sent either by way of mutations like with
> read repair, or by streaming sstables. But it would be small amounts
> of data that will act roughly the same as regular writes for the
> perspective of compaction.
> Some nice properties of this approach:
> * It's "always on"; no periodic sudden effects on cluster performance.
> * Restarting n
[jira] [Commented] (CASSANDRA-2699) continuous incremental anti-entropy
[
https://issues.apache.org/jira/browse/CASSANDRA-2699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583453#comment-13583453
]
Benjamin Coverston commented on CASSANDRA-2699:
---
>From CASSANDRA-4482
{quote}
Instead, we maintain a Merkle Tree (MT) in memory and update it with every
single column insert in ColumnFamilyStore.apply(). We use
column.updateDigest(digest) on all the changes in order to create a hash per
column update and then XOR this hash with the existing one in the Merkle Tree
bucket for the corresponding row.
This Merkle Tree is created with the column family (one per range), initialized
with zeros, and persisted to disk with regular snapshots.
The commutative properties of XOR make it possible to update the MT
incrementally without having to read on write.
{quote}
I'm pretty sure this means that we should be able to XOR the buckets together
from pre-computed merkle tree SSTable components.
We could just create these on flush, merge them on compaction, then validation
compaction is just a read, MT components and merge.
> continuous incremental anti-entropy
> ---
>
> Key: CASSANDRA-2699
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2699
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Peter Schuller
>Assignee: Peter Schuller
>
> Currently, repair works by periodically running "bulk" jobs that (1)
> performs a validating compaction building up an in-memory merkle tree,
> and (2) streaming ring segments as needed according to differences
> indicated by the merkle tree.
> There are some disadvantages to this approach:
> * There is a trade-off between memory usage and the precision of the
> merkle tree. Less precision means more data streamed relative to
> what is strictly required.
> * Repair is a periodic "bulk" process that runs for a significant
> period and, although possibly rate limited as compaction (if 0.8 or
> backported throttling patch applied), is a divergence in terms of
> performance characteristics from "normal" operation of the cluster.
> * The impact of imprecision can be huge on a workload dominated by I/O
> and with cache locality being critical, since you will suddenly
> transfers lots of data to the target node.
> I propose a more incremental process whereby anti-entropy is
> incremental and continuous over time. In order to avoid being
> seek-bound one still wants to do work in some form of bursty fashion,
> but the amount of data processed at a time could be sufficiently small
> that the impact on the cluster feels a lot more continuous, and that
> the page cache allows us to avoid re-reading differing data twice.
> Consider a process whereby a node is constantly performing a per-CF
> repair operation for each CF. The current state of the repair process
> is defined by:
> * A starting timestamp of the current iteration through the token
> range the node is responsible for.
> * A "finger" indicating the current position along the token ring to
> which iteration has completed.
> This information, other than being in-memory, could periodically (every
> few minutes or something) be stored persistently on disk.
> The finger advances by the node selecting the next small "bit" of the
> ring and doing whatever merkling/hashing/checksumming is necessary on
> that small part, and then asking neighbors to do the same, and
> arranging for neighbors to send the node data for mismatching
> ranges. The data would be sent either by way of mutations like with
> read repair, or by streaming sstables. But it would be small amounts
> of data that will act roughly the same as regular writes for the
> perspective of compaction.
> Some nice properties of this approach:
> * It's "always on"; no periodic sudden effects on cluster performance.
> * Restarting nodes never cancels or breaks anti-entropy.
> * Huge compactions of entire CF:s never clog up the compaction queue
> (not necessarily a non-issue even with concurrent compactions in
> 0.8).
> * Because we're always operating on small chunks, there is never the
> same kind of trade-off for memory use. A merkel tree or similar
> could be calculated at a very detailed level potentially. Although
> the precision from the perspective of reading from disk would likely
> not matter much if we are in page cache anyway, very high precision
> could be *very* useful when doing anti-entropy across data centers
> on slow links.
> There are devils in details, like how to select an appropriate ring
> segment given that you don't have knowledge of the data density on
> other nodes. But I feel that the overall idea/process seems very
> promising.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
Fo
[jira] [Comment Edited] (CASSANDRA-5271) Create tool to drop sstables to level 0
[ https://issues.apache.org/jira/browse/CASSANDRA-5271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583351#comment-13583351 ] Marcus Eriksson edited comment on CASSANDRA-5271 at 2/21/13 4:55 PM: - v2 also contains debian packaging i added sstablemetadata as well was (Author: krummas): debian packaging > Create tool to drop sstables to level 0 > --- > > Key: CASSANDRA-5271 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5271 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Trivial > Labels: tools > Fix For: 2.0 > > Attachments: 0001-Add-tool-to-drop-sstables-back-to-level-0.patch, > 0001-Add-tool-to-drop-sstables-back-to-level-0-v2.patch > > > after CASSANDRA-4872 we need a way to reset all sstables to level 0, > previously we did this by removing the .json file from the data-directory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5271) Create tool to drop sstables to level 0
[ https://issues.apache.org/jira/browse/CASSANDRA-5271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-5271: --- Attachment: 0001-Add-tool-to-drop-sstables-back-to-level-0-v2.patch debian packaging > Create tool to drop sstables to level 0 > --- > > Key: CASSANDRA-5271 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5271 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Trivial > Labels: tools > Fix For: 2.0 > > Attachments: 0001-Add-tool-to-drop-sstables-back-to-level-0.patch, > 0001-Add-tool-to-drop-sstables-back-to-level-0-v2.patch > > > after CASSANDRA-4872 we need a way to reset all sstables to level 0, > previously we did this by removing the .json file from the data-directory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4131) Integrate Hive support to be in core cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583263#comment-13583263 ] Chris Romary commented on CASSANDRA-4131: - Wondering about the status of Cassandra/Hive integration... is it a 'left-for-dead external shim' or something that's still actively being worked on? None of the githubs mentioned above have commits in the last 10 months or so. What is the status of Hive/Cassandra 1.2? > Integrate Hive support to be in core cassandra > -- > > Key: CASSANDRA-4131 > URL: https://issues.apache.org/jira/browse/CASSANDRA-4131 > Project: Cassandra > Issue Type: Improvement >Reporter: Jeremy Hanna >Assignee: Edward Capriolo > Labels: hadoop, hive > > The standalone hive support (at https://github.com/riptano/hive) would be > great to have in-tree so that people don't have to go out to github to > download it and wonder if it's a left-for-dead external shim. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5051) Allow automatic cleanup after gc_grace
[ https://issues.apache.org/jira/browse/CASSANDRA-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-5051: -- Attachment: (was: 3430-v3.txt) > Allow automatic cleanup after gc_grace > -- > > Key: CASSANDRA-5051 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5051 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Brandon Williams >Assignee: Vijay > Labels: vnodes > Fix For: 2.0 > > Attachments: 0001-CASSANDRA-5051.patch > > > When using vnodes, after adding a new node you have to run cleanup on all the > machines, because you don't know which are affected and chances are it was > most if not all of them. As an alternative to this intensive process, we > could allow cleanup during compaction if the data is older than gc_grace (or > perhaps some other time period since people tend to use gc_grace hacks to get > rid of tombstones.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3430) Break Big Compaction Lock apart
[
https://issues.apache.org/jira/browse/CASSANDRA-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-3430:
--
Attachment: 3430-v3.txt
v3 adds an extra assert that is failing in CompactionsTest. Not sure why.
{code}
.
CompactionManager.instance.interruptCompactionFor(Collections.singleton(metadata));
while (CompactionManager.instance.isCompacting(metadata))
FBUtilities.sleep(100);
assert data.getCompacting().isEmpty();
{code}
> Break Big Compaction Lock apart
> ---
>
> Key: CASSANDRA-3430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3430
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Jonathan Ellis
>Assignee: Jonathan Ellis
>Priority: Minor
> Labels: compaction
> Fix For: 2.0
>
> Attachments: 3430-1.0.txt, 3430-1.1.txt, 3430-v2.txt, 3430-v3.txt
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-5051) Allow automatic cleanup after gc_grace
[
https://issues.apache.org/jira/browse/CASSANDRA-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5051:
--
Attachment: 3430-v3.txt
v3 adds an extra assert that is failing in CompactionsTest. Not sure why.
{code}
.
CompactionManager.instance.interruptCompactionFor(Collections.singleton(metadata));
while (CompactionManager.instance.isCompacting(metadata))
FBUtilities.sleep(100);
assert data.getCompacting().isEmpty();
{code}
> Allow automatic cleanup after gc_grace
> --
>
> Key: CASSANDRA-5051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5051
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
>Reporter: Brandon Williams
>Assignee: Vijay
> Labels: vnodes
> Fix For: 2.0
>
> Attachments: 0001-CASSANDRA-5051.patch, 3430-v3.txt
>
>
> When using vnodes, after adding a new node you have to run cleanup on all the
> machines, because you don't know which are affected and chances are it was
> most if not all of them. As an alternative to this intensive process, we
> could allow cleanup during compaction if the data is older than gc_grace (or
> perhaps some other time period since people tend to use gc_grace hacks to get
> rid of tombstones.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Deleted] (CASSANDRA-5051) Allow automatic cleanup after gc_grace
[
https://issues.apache.org/jira/browse/CASSANDRA-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-5051:
--
Comment: was deleted
(was: v3 adds an extra assert that is failing in CompactionsTest. Not sure why.
{code}
.
CompactionManager.instance.interruptCompactionFor(Collections.singleton(metadata));
while (CompactionManager.instance.isCompacting(metadata))
FBUtilities.sleep(100);
assert data.getCompacting().isEmpty();
{code})
> Allow automatic cleanup after gc_grace
> --
>
> Key: CASSANDRA-5051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5051
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
>Reporter: Brandon Williams
>Assignee: Vijay
> Labels: vnodes
> Fix For: 2.0
>
> Attachments: 0001-CASSANDRA-5051.patch, 3430-v3.txt
>
>
> When using vnodes, after adding a new node you have to run cleanup on all the
> machines, because you don't know which are affected and chances are it was
> most if not all of them. As an alternative to this intensive process, we
> could allow cleanup during compaction if the data is older than gc_grace (or
> perhaps some other time period since people tend to use gc_grace hacks to get
> rid of tombstones.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3430) Break Big Compaction Lock apart
[ https://issues.apache.org/jira/browse/CASSANDRA-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-3430: -- Attachment: 3430-v2.txt v2 attached that removes compactionLock entirely, instead relying on disabling + cancelling current compactions for exceptional operations (vis., major compaction + truncate). reloading the CompactionStrategy is synchronized vs runWithCompactionsDisabled; otherwise, we're okay with allowing an old compaction strategy to finish in-progress work after installing a new one: markCompacting, which we respect more thoroughly after CASSANDRA-5256, keeps this from being dangerous, and it may end up saving us some work. > Break Big Compaction Lock apart > --- > > Key: CASSANDRA-3430 > URL: https://issues.apache.org/jira/browse/CASSANDRA-3430 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Jonathan Ellis >Priority: Minor > Labels: compaction > Fix For: 2.0 > > Attachments: 3430-1.0.txt, 3430-1.1.txt, 3430-v2.txt > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "Valeria43" by Valeria43
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "Valeria43" page has been changed by Valeria43: http://wiki.apache.org/cassandra/Valeria43 New page: Hey guys !! I am CELIA PRATT. I reside in Reno. Soon i will turn 51.<> I go to night school at The Personalized Institute situated in Aurora. I have a job as Plumber. My hobby is Coin Collecting. My father name is Matthew and he is a Locksmith. My mummy is a Etymologist.<> <> Here is my blog post: [[http://www.youtube.com/watch?v=twJ_8IgGmgk|rhinestone shoes]]
[jira] [Commented] (CASSANDRA-5074) Add an official way to disable compaction
[ https://issues.apache.org/jira/browse/CASSANDRA-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583140#comment-13583140 ] Andrea Gazzarini commented on CASSANDRA-5074: - Probably that wasn't clear, but honestly I believe it's a problem of mine: I have just a little bit of experience on Cassandra source code and its internal architecture. Ok, now I think I got the point about your idea, so I will continue investigating the code in order to implement that. A question: in case the logic is moved on the CompactionMananger, what should be, from client point of view, a nice and good way to indicate that the (background) compaction must be disabled? I believe the command line of my previous post is no longer appropriate > create column family XYZ with compaction_strategy=NoCompactionStrategy > Add an official way to disable compaction > - > > Key: CASSANDRA-5074 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5074 > Project: Cassandra > Issue Type: Bug >Reporter: Jonathan Ellis >Priority: Minor > Fix For: 1.2.2 > > > We've traditionally used "min or max compaction threshold = 0" to disable > compaction, but this isn't exactly intuitive and it's inconsistently > implemented -- allowed from jmx, not allowed from cli. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Trivial Update of "MaximoPur" by MaximoPur
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "MaximoPur" page has been changed by MaximoPur: http://wiki.apache.org/cassandra/MaximoPur New page: I am from Waco. I am 35. I study at The Startling Boarding School which has a branch in Simi Valley.<> <> I work as a Guard. My father name is Kevin M and he is a Treasurer. My mummy is a Cardiologist.<> <> Also visit my blog: [[http://www.foundbeatsbydre.com|beats by dre monster]]
[Cassandra Wiki] Trivial Update of "Felipe08D" by Felipe08D
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "Felipe08D" page has been changed by Felipe08D: http://wiki.apache.org/cassandra/Felipe08D New page: Hey guys !! My name is GERALDINE WILKERSON. I have a house in Kissimmee.<> I am turning 49. I might join The Instructive Military School which has a branch in Green Bay. I am planning to become a Technical engineer. My daddy name is Tony and he is a Webmaster. My momy is a Writer.<> <> My webpage: [[http://www.reachbeatsbydre.com|monster headphones]]
[Cassandra Wiki] Trivial Update of "Omar9973" by Omar9973
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "Omar9973" page has been changed by Omar9973: http://wiki.apache.org/cassandra/Omar9973 New page: Hey guys !! I am MICAH VALENZUELA. I reside in Monterey.<> I am turning 48. I am taking admission in The Kind Prep School of Liberal People situated in Downey. I work as a Bargeman. My hobby is Acting. My dad name is Craig and he is a Paleoseismologist. My mom is a Matron.<> <> my homepage [[http://onlinestore-chanel-handbags.yolasite.com|chanel handbags]]
