Probably a jvm check and a new output that didn’t exist previously - which
version of the jdk? Also are you using a weird shell or exporting weird java
home or aliases?
--
Jeff Jirsa
> On May 10, 2019, at 12:16 PM, Michael Shuler wrote:
>
>> On 5/10/19 2:00 PM, Lou DeGenaro wrote:
>> cassa
On 5/10/19 2:00 PM, Lou DeGenaro wrote:
cassandra-server/bin$ ./nodetool help
./nodetool: 333: [: Oracle: unexpected operator
usage: nodetool [(-u | --username )]
...
What version of Cassandra? That line number is strange. The string
"Oracle" along with other garbage seems to be coming from p
cassandra-server/bin$ ./nodetool help
./nodetool: 333: [: Oracle: unexpected operator
usage: nodetool [(-u | --username )]
...
Why might I get the above "unexpected error"?
Thx.
Lou.
Hello Roy,
The name of the table makes me think that you might be doing automated
changes to the schema. I just dug this topic for someone else and schema
changes are way less consistent than standard Cassandra operations (see
https://issues.apache.org/jira/browse/CASSANDRA-10699).
> sessions_raw
Hello Mark
Second, any ideas what could be creating bottlenecks for schema alteration?
I am not too sure what could be going on to make things that long, but
about the corrupted data, I've seen it before. Here are some thoughts
around schema changes and finding the bottlenecks:
Ideally, use co
i will try with changing java version.
w.r.t other point about hardware, i have this issue in multiple setups. so
i really doubt if hardware is playing spoilsport here
On 10-May-2019 11:38, "Jeff Jirsa" wrote:
> It’s going to be very difficult to diagnose remotely.
>
> I don’t run or have an opi
