This is because Cassandra sets -XX:+PerfDisableSharedMem JVM option by default.
This prevents tools such as jps to list jvm processes.
See https://issues.apache.org/jira/browse/CASSANDRA-9242 for detail.
You can work around by doing what Riccardo said.
On Tue, Sep 18, 2018 at 9:41 PM Philip Ó Cond
pdate the version into
> 2.1.13?
>
> And, my table already had 560 millions of records. So, for resolving this,
> Whether I only need to update the new version C*.jar
> and restart cassandra?
>
> Dillon
>
> 2015-12-29 7:36 GMT+08:00 Yuki Morishita :
>>
>> T
r.java:330)
> ... 2 more
>
> I don't know whether this error is relative to one of cluster nodes' linux
> crash?
>
> Any advice will be appreciated!
>
> Dillon Peng
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
ecutor.java:615)
>> [na:1.7.0_80]
>> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_80]
>> Caused by: java.io.IOException: Failed during snapshot creation.
>> at
>> org.apache.cassandra.repair.RepairSession.failedSnapshot(RepairSession.java:344)
>> ~[apache-cassandra-2.1.5.jar:2.1.5]
>> at org.apache.cassandra.repair.RepairJob$2.onFailure(RepairJob.java:146)
>> ~[apache-cassandra-2.1.5.jar:2.1.5]
>> at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172)
>> ~[guava-16.0.jar:na]
>> ... 3 common frames omitted
>>
>>
>
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
5.1.1, related issue?
>
>
>
> This email (including any attachments) is proprietary to Aspect Software,
> Inc. and may contain information that is confidential. If you have received
> this message in error, please do not read, copy or forward this message.
> Please notify the
We're also seeing lagging compactions and high cpu
> usage.
>
>
> Thanks, Don
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
of
> $DATE, or that to repair everything as of $DATE I must repair ranges $X?
>
> https://gist.github.com/autocracy/9467eaaff581ff24334c
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
.
>
>
> If cleanup is still excepting for you on 2.0.13 with some sstables you have,
> I would strongly consider :
>
> 1) file a JIRA (http://issues.apache.org) and attach / offer the sstables
> for debugging
> 2) let the list know the JIRA id of the ticket
>
> =Rob
>
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
Thanks!
On Thu, Mar 5, 2015 at 11:10 AM, Aby Kuruvilla
wrote:
> Thanks Yuki, have created a JIRA ticket
>
> https://issues.apache.org/jira/browse/CASSANDRA-8924
>
> On Thu, Mar 5, 2015 at 10:34 AM, Yuki Morishita wrote:
>>
>> Thanks.
>> It looks like a bug
ete
> WARN [STREAM-IN-/127.0.0.1] 2015-03-04 09:20:23,829
> StreamResultFuture.java:207 - [Stream #98ba8730-c279-11e4-b8e9-55374d280508]
> Stream failed
>
>
>
> On Wed, Mar 4, 2015 at 1:18 PM, Yuki Morishita wrote:
>>
>> Do you have corresponding error in t
E TABLE dev.participant()");
>
> CqlBulkOutputFormat.setColumnFamilyInsertStatement(job.getConfiguration(),
> CASSANDRA_TABLE_NAME, "INSERT into dev.participant() values
> (?,?,?,?,?) ");
>
> .
> }
>
> }
>
> Reducer Code
>
> public class ReducerToCassandra extends Reducer List> {
>
> private MultipleOutputs multipleOutputs;
>
> @SuppressWarnings("unchecked")
>protected void setup(Context context) throws IOException,
> InterruptedException {
> multipleOutputs = new MultipleOutputs(context);
>}
>
> @Override
>public void reduce(Text id, Iterable pInfo, Context context) throws
> IOException, InterruptedException {
>
>List bVariables = new ArrayList();
>
> .
> multipleOutputs.write(CASSANDRA_TABLE1, null, bVariables);
>
> }
>
>
>
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
action you
> will have one active SSTable5 which is newly written and consumes space. The
> snapshot-linked ones are still there, still consuming their space. Only when
> this snapshot is cleared you get your disk space back.
>
> HTH,
> Jan
>
>
>
>
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
u are
>> not the intended recipient, any dissemination, use,
>> review, distribution, printing or copying of the
>> information contained in this e-mail message
>> and/or attachments to it are strictly prohibited. If
>> you have received this communication in error,
>> please notify us by reply e-mail or telephone and
>> immediately and permanently delete the message
>> and any attachments. Thank you
>
>
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
1)
>at
> com.sun.jmx.remote.internal.ClientNotifForwarder$LinearExecutor$1.run(ClientNotifForwarder.java:107)
>
> This error was followed by lots of “Lost Notification” messages.
> Node became unusable and I had to restart it. Is this an issue?
>
> Rafal
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
is...
>
> Repair gets much slower, bootstrapping gets faster and better distributed.
>
> https://issues.apache.org/jira/browse/CASSANDRA-5220
>
> Is a good starting point for the web of related JIRA tickets.
>
> =Rob
> http://twitter.com/rcolidba
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
some columns where the TTL has expired, i.e. the
> sstable has not yet been compacted - will those entries be properly
> removed on the destination side?
>
> Thanks,
> \EF
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
ng 2.0.7 with vnodes. Any
> insight into what might be causing these OOMs and/or what version this
> -snapshot option is available in?
>
> Thanks!
>
> Phil
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
two counter families ?
>
>
>
> Thanks.
>
>
>
> Regards,
>
> Dominique
>
>
>
>
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
y to verify if the token ranges overlap to decide if a
>> tombstone compaction must be executed on a single SSTable with high
>> droppable tombstone ratio.
>>
>> Any clarification would be kindly appreciated.
>>
>> PS: Cassandra version: 1.2.16
>>
>> --
>> Paulo Motta
>>
>> Chaordic | Platform
>> www.chaordic.com.br
>> +55 48 3232.3200
>
>
>
>
> --
> Paulo Motta
>
> Chaordic | Platform
> www.chaordic.com.br
> +55 48 3232.3200
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
-pr will work again. That's correct
> ?
>
> 2014-02-27 19:15 GMT+01:00 Yuki Morishita :
>> Yes, it is expected behavior since
>> 1.2.5(https://issues.apache.org/jira/browse/CASSANDRA-5424).
>> Since you set foobar not to replicate to stats dc, primary ran
rimary range token should have been repaired in the two
> others DC ? Am I wrong ?
>
> We are using cassandra 1.2.13, with 256 vnodes and Murmur3Partitioner
>
>
> --
> Close the World, Open the Net
> http://www.linux-wizard.net
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
;
>>
>> This seems like a bug in sstableloader, I would report it on JIRA.
>>
>>>
>>> Naturally, copying the data again doesn't work to fix it, as the
>>> tombstone is far in the future. Apart from not having this happen at
>>> all, how can it be fixed?
>>
>>
>> Briefly, you'll want to purge that tombstone and then reload the data with a
>> reasonable timestamp.
>>
>> Dealing with rows with data (and tombstones) in the far future is described
>> in detail here :
>>
>> http://thelastpickle.com/blog/2011/12/15/Anatomy-of-a-Cassandra-Partition.html
>>
>> =Rob
>>
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
en
> ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt
> auf welche Weise auch immer zu verwenden.
>
> This E-Mail may contain confidential and/or privileged information. If you
> are not the intended recipient of this E-Mail, you are hereby notified that
> saving, distribution or use of the content of this E-Mail in any way is
> prohibited. If you have received this E-Mail in error, please notify the
> sender and delete the E-Mail.
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
s looking at one column enough to
> trigger a read repair ?
>
>
> 2) Can someone explain to me how the repair works such that I don't totally
> trash my cluster or spill into work week ?
>
>
> Is there any improvement and clarity in 1.2 ? How about 2.0 ?
>
>
>
>
> --
>
> Regards,
>
> Oleg Dulin
>
> http://www.olegdulin.com
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
ra.streaming.messages.StreamMessage.serialize(StreamMessage.java:44)
> at
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:384)
> at
> org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:357)
> at ja
d suggest this works – we had 60G of data
> with TTL=1week pushed a while ago to the test cluster, the majority of it
> should be expired & compacted away by now. Not sure if it is relevant, but
> this old data is in one ~60G file + I have a few smaller files with latest
> data in them.
>
> Looking at JMX: DroppableTombstoneRatio = 0.892076544, which seems to back
> my theory.
>
> Am I doing something wrong, or am I expecting the wrong thing?
>
>
>
> Thanks,
>
> Tamas
>
>
>
>
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
ompressed data / original" or "original/ compressed" ? Or
> something else.
>
> thanks a lot.
>
> Best Regards,
> Cem
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
nputStream$Reader.runMay
> Throw(CompressedInputStream.java:151)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at java.lang.Thread.run(Thread.java:662)
>
>
>
>
> On 5/23/13 9:51 AM, "Yuki Morishita" wrote:
>
&
repair just yet to avoid it and try synching via another means. It seems
> on a streaming failure, it never recovers from this. Any ideas?
>
> We are on cassandra 1.2.2
>
> Thanks,
> Dean
>
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
> overlaps.size() and keys and remainingKeys:
>
> overlaps.size() is around 30, number of keys for that sstable is around 5 M
> and remainingKeys is always 0.
>
> Are you sure that it is a good idea to estimate remainingKeys like that?
>
> Best Regards,
> Cem
>
>
>
> On We
used.
>
> In my use case I generate a GUID for each key and send a single write
> request.
>
> Cem
>
> On Tue, May 21, 2013 at 11:13 PM, Yuki Morishita wrote:
>>
>> > Why does Cassandra single table compaction skips the keys that are in
>> > the other sst
case and the droppableRatio is
> 0.9. Cassandra skips all sstables which are already expired.
>
> This line was introduced by
> https://issues.apache.org/jira/browse/CASSANDRA-4022.
>
> Best Regards,
> Cem
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
Index.db file always contains *all* position of the keys in data file.
index_interval is the rate that the position of the key in index file is store
in memory.
So that C* can begin scanning index file from closest position.
On Friday, March 22, 2013 at 11:17 AM, Hiller, Dean wrote:
> I was ju
t; RowMutationVerbHandler.java (line 40) Applying mutation
> DEBUG [MutationStage:602] 2013-03-15 14:32:33,643
> AbstractSimplePerColumnSecondaryIndex.java (line 118) applying index row
> us.countryproducts.safestchina.com
>
> Thanks,
>
> Daning
>
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
Are you sure you are using 1.2.2?
Because LegacyLeveledManifest is from unreleased development version.
On Friday, March 8, 2013 at 11:02 PM, Arya Goudarzi wrote:
> Hi,
>
> I am exercising the rolling upgrade from 1.1.6 to 1.2.2. When I upgraded to
> 1.2.2 on the first node, during startup I g
no. sstables are eventually compacted and moved to next level.
On Friday, March 8, 2013, Kanwar Sangha wrote:
> Cool ! So of we exceed the threshold, is that an issue… ?
>
> ** **
>
> *From:* Yuki Morishita [mailto:mor.y...@gmail.com 'cvml', 'mor.y...@gmail.co
It is SSTable counts in each level.
> SSTables in each level: [40/4, 442/10, 97, 967, 7691, 0, 0, 0]
So you have 40 SSTables in L0, 442 in L1, 97 in L2 and so forth.
'40/4' and '442/10' have numbers after slash, those are expected maximum number
of
SSTables in that level and only displayed when
Alexel,
You were right.
It was already fixed to use UUID for streaming session and released in 1.2.0.
See https://issues.apache.org/jira/browse/CASSANDRA-4813.
On Thursday, January 24, 2013 at 6:49 AM, Alexei Bakanov wrote:
> Hello,
>
> We see that BulkOutputFormat fails to stream data from mu
Due to the change in directory structure from ver 1.1, you have to create the
directory like
/path/to/sstables//
and put your sstables.
In your case, I think it would be "/data/ssTable/tpch/tpch/cf0".
And you have to specify that directory as a parameter for sstableloader
bin/sstableloader -
Thierry,
Key cache files are stored inside your saved_caches_directory defined in
cassandra.yaml, which has default value of /var/lib/cassandra/saved_caches.
Yuki
On Monday, July 2, 2012 at 4:00 AM, Thierry Templier wrote:
> Hello Yuki,
>
> Could you give me hints about where to find these
That was bug in 1.1.1 and fixed in
https://issues.apache.org/jira/browse/CASSANDRA-4331.
Workaround is deleting the key cache files for your index CFs should fix this.
Yuki
On Friday, June 29, 2012 at 10:02 AM, Thierry Templier wrote:
> Hello,
>
> My problem seems to occur after a server re
You can open JIRA ticket at https://issues.apache.org/jira/browse/CASSANDRA
with your proposal.
Just for the input:
I had once implemented HyperLogLog counter to use internally in Cassandra, but
it turned out I didn't need it so I just put it to gist. You can find it here:
https://gist.github.
Data will not be deleted when those keys appear in other stables outside of
compaction. This is to prevent obsolete data from appearing again.
yuki
On Tuesday, May 22, 2012 at 7:37 AM, Pieter Callewaert wrote:
>
> Hi Samal,
>
>
>
>
>
> Thanks for your time looking into this.
>
>
Erik,
Currently, streaming failure handling is poorly functioning.
There are several discussions and bug reports regarding streaming failure on
jira.
Hanged streaming session will be left in memory unless you restart C*, but it
does not cause problem I believe.
--
Yuki Morishita
On
Also note that Cassandra project switched to git from svn.
See "Source control" section of http://cassandra.apache.org/download/ .
Regards,
Yuki
--
Yuki Morishita
On Thursday, January 5, 2012 at 7:59 PM, Maki Watanabe wrote:
> Sorry, ignore my reply.
> I had same result
rsion:
http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=ja&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fec-cube.ec-orange.jp%2Flp%2Fcassandra-conference-in-tokyo%2F&act=url
If you're around Tokyo and willing to attend, but not fluent in
Japanese,
lis
>> Lead Software Engineer
>> Agentis Energy
>> www.agentisenergy.com
>> o: 630.359.6395
>> c: 219.384.5143
>> A Smart Grid technology company focused on helping consumers of energy
>> control an often under-managed resource.
>>
>>
>
>
>
> --
> w3m
>
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
in error, please
> destroy and notify the sender. Any use of this email is prohibited when
> received in error. Impetus does not represent, warrant and/or guarantee,
> that the integrity of this communication has been maintained nor that the
> communication is free of errors, virus, inte
ld be allowed: http://wiki.apache.org/cassandra/API
>
> Regards,
>
> Gary.
>
>
> On Tue, Jun 1, 2010 at 21:50, Yuki Morishita wrote:
>> Hi,
>>
>> I'm testing several read operations(get, get_slice, get_count, etc.) with
>> various ConsistencyLevel and
to be able to handle CL.ALL, but in thrift.CassandraServer#readColumnFamily,
there is code that just throws exception when consistency_level == ALL.
Is there any reason that CL.ALL is "not yet supported"?
Yuki Morishita
t:yukim (http://twitter.com/yukim)
wse/INFRA-2741
>
> On Sun, May 23, 2010 at 10:09 PM, Yuki Morishita wrote:
>> Hi all,
>>
>> I'm currently working on translating cassandra wiki to Japanese.
>> Cassandra is gaining attention in Japan, too. :)
>>
>> I noticed that for those who have brow
ivilege to edit Japanese front page above?
Or, can someone from dev team edit above front page so that everyone
with browser locale 'ja' get redirected to 'FrontPage_JP'?
(Just put '#redirect FrontPage_JP' in first line of
http://wiki.apache.org/cassandra/フロントページ)
Thanks i
52 matches
Mail list logo
