[jira] [Commented] (CASSANDRA-13547) Filtered materialized views missing data
[
https://issues.apache.org/jira/browse/CASSANDRA-13547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071984#comment-16071984
]
Krishna Dattu Koneru commented on CASSANDRA-13547:
--
Hi [~jasonstack] ,
Here is another go at patch which addresses {{1.Missing Update}} .With Current
implementation of ColumFamily all columns in metadata will be written to disk.
So,I had to add another class member in {{ViewDefinition.java}} to keep track
of all columns used in the view definition.
And regarding your comment on {{2. incorrect non-pk tombstones}} ,
https://issues.apache.org/jira/browse/CASSANDRA-11500 is already open for this
issue.
||patch||test||
|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...krishna-koneru:cassandra-3.11-13547]|[circleci|https://circleci.com/gh/krishna-koneru/cassandra/13]|
Thanks !
> Filtered materialized views missing data
>
>
> Key: CASSANDRA-13547
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13547
> Project: Cassandra
> Issue Type: Bug
> Components: Materialized Views
> Environment: Official Cassandra 3.10 Docker image (ID 154b919bf8ce).
>Reporter: Craig Nicholson
>Assignee: Krishna Dattu Koneru
>Priority: Blocker
> Labels: materializedviews
> Fix For: 3.11.x
>
>
> When creating a materialized view against a base table the materialized view
> does not always reflect the correct data.
> Using the following test schema:
> {code:title=Schema|language=sql}
> DROP KEYSPACE IF EXISTS test;
> CREATE KEYSPACE test
> WITH REPLICATION = {
>'class' : 'SimpleStrategy',
>'replication_factor' : 1
> };
> CREATE TABLE test.table1 (
> id int,
> name text,
> enabled boolean,
> foo text,
> PRIMARY KEY (id, name));
> CREATE MATERIALIZED VIEW test.table1_mv1 AS SELECT id, name, foo
> FROM test.table1
> WHERE id IS NOT NULL
> AND name IS NOT NULL
> AND enabled = TRUE
> PRIMARY KEY ((name), id);
> CREATE MATERIALIZED VIEW test.table1_mv2 AS SELECT id, name, foo, enabled
> FROM test.table1
> WHERE id IS NOT NULL
> AND name IS NOT NULL
> AND enabled = TRUE
> PRIMARY KEY ((name), id);
> {code}
> When I insert a row into the base table the materialized views are updated
> appropriately. (+)
> {code:title=Insert row|language=sql}
> cqlsh> INSERT INTO test.table1 (id, name, enabled, foo) VALUES (1, 'One',
> TRUE, 'Bar');
> cqlsh> SELECT * FROM test.table1;
> id | name | enabled | foo
> +--+-+-
> 1 | One |True | Bar
> (1 rows)
> cqlsh> SELECT * FROM test.table1_mv1;
> name | id | foo
> --++-
> One | 1 | Bar
> (1 rows)
> cqlsh> SELECT * FROM test.table1_mv2;
> name | id | enabled | foo
> --++-+-
> One | 1 |True | Bar
> (1 rows)
> {code}
> Updating the record in the base table and setting enabled to FALSE will
> filter the record from both materialized views. (+)
> {code:title=Disable the row|language=sql}
> cqlsh> UPDATE test.table1 SET enabled = FALSE WHERE id = 1 AND name = 'One';
> cqlsh> SELECT * FROM test.table1;
> id | name | enabled | foo
> +--+-+-
> 1 | One | False | Bar
> (1 rows)
> cqlsh> SELECT * FROM test.table1_mv1;
> name | id | foo
> --++-
> (0 rows)
> cqlsh> SELECT * FROM test.table1_mv2;
> name | id | enabled | foo
> --++-+-
> (0 rows)
> {code}
> However a further update to the base table setting enabled to TRUE should
> include the record in both materialzed views, however only one view
> (table1_mv2) gets updated. (-)
> It appears that only the view (table1_mv2) that returns the filtered column
> (enabled) is updated. (-)
> Additionally columns that are not part of the partiion or clustering key are
> not updated. You can see that the foo column has a null value in table1_mv2.
> (-)
> {code:title=Enable the row|language=sql}
> cqlsh> UPDATE test.table1 SET enabled = TRUE WHERE id = 1 AND name = 'One';
> cqlsh> SELECT * FROM test.table1;
> id | name | enabled | foo
> +--+-+-
> 1 | One |True | Bar
> (1 rows)
> cqlsh> SELECT * FROM test.table1_mv1;
> name | id | foo
> --++-
> (0 rows)
> cqlsh> SELECT * FROM test.table1_mv2;
> name | id | enabled | foo
> --++-+--
> One | 1 |True | null
> (1 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: co
[jira] [Assigned] (CASSANDRA-13576) test failure in bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test
[
https://issues.apache.org/jira/browse/CASSANDRA-13576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang reassigned CASSANDRA-13576:
Assignee: ZhaoYang
> test failure in
> bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test
> -
>
> Key: CASSANDRA-13576
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13576
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Hamm
>Assignee: ZhaoYang
> Labels: dtest, test-failure
> Attachments: node1_debug.log, node1_gc.log, node1.log,
> node2_debug.log, node2_gc.log, node2.log, node3_debug.log, node3_gc.log,
> node3.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/445/testReport/bootstrap_test/TestBootstrap/consistent_range_movement_false_with_rf1_should_succeed_test
> {noformat}
> Error Message
> 31 May 2017 04:28:09 [node3] Missing: ['Starting listening for CQL clients']:
> INFO [main] 2017-05-31 04:18:01,615 YamlConfigura.
> See system.log for remainder
> {noformat}
> {noformat}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/bootstrap_test.py", line 236, in
> consistent_range_movement_false_with_rf1_should_succeed_test
> self._bootstrap_test_with_replica_down(False, rf=1)
> File "/home/automaton/cassandra-dtest/bootstrap_test.py", line 278, in
> _bootstrap_test_with_replica_down
>
> jvm_args=["-Dcassandra.consistent.rangemovement={}".format(consistent_range_movement)])
> File
> "/home/automaton/venv/local/lib/python2.7/site-packages/ccmlib/node.py", line
> 696, in start
> self.wait_for_binary_interface(from_mark=self.mark)
> File
> "/home/automaton/venv/local/lib/python2.7/site-packages/ccmlib/node.py", line
> 514, in wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> File
> "/home/automaton/venv/local/lib/python2.7/site-packages/ccmlib/node.py", line
> 471, in watch_log_for
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S", time.gmtime()) + "
> [" + self.name + "] Missing: " + str([e.pattern for e in tofind]) + ":\n" +
> reads[:50] + ".\nSee {} for remainder".format(filename))
> "31 May 2017 04:28:09 [node3] Missing: ['Starting listening for CQL
> clients']:\nINFO [main] 2017-05-31 04:18:01,615 YamlConfigura.\n
> {noformat}
> {noformat}
> >> begin captured logging <<
> \ndtest: DEBUG: cluster ccm directory:
> /tmp/dtest-PKphwD\ndtest: DEBUG: Done setting configuration options:\n{
> 'initial_token': None,\n'memtable_allocation_type': 'offheap_objects',\n
> 'num_tokens': '32',\n'phi_convict_threshold': 5,\n
> 'range_request_timeout_in_ms': 1,\n'read_request_timeout_in_ms':
> 1,\n'request_timeout_in_ms': 1,\n
> 'truncate_request_timeout_in_ms': 1,\n'write_request_timeout_in_ms':
> 1}\ncassandra.policies: INFO: Using datacenter 'datacenter1' for
> DCAwareRoundRobinPolicy (via host '127.0.0.1'); if incorrect, please specify
> a local_dc to the constructor, or limit contact points to local cluster
> nodes\ncassandra.cluster: INFO: New Cassandra host datacenter1> discovered\ncassandra.protocol: WARNING: Server warning: When
> increasing replication factor you need to run a full (-full) repair to
> distribute the data.\ncassandra.connection: WARNING: Heartbeat failed for
> connection (139927174110160) to 127.0.0.2\ncassandra.cluster: WARNING: Host
> 127.0.0.2 has been marked down\ncassandra.pool: WARNING: Error attempting to
> reconnect to 127.0.0.2, scheduling retry in 2.0 seconds: [Errno 111] Tried
> connecting to [('127.0.0.2', 9042)]. Last error: Connection
> refused\ncassandra.pool: WARNING: Error attempting to reconnect to 127.0.0.2,
> scheduling retry in 4.0 seconds: [Errno 111] Tried connecting to
> [('127.0.0.2', 9042)]. Last error: Connection refused\ncassandra.pool:
> WARNING: Error attempting to reconnect to 127.0.0.2, scheduling retry in 8.0
> seconds: [Errno 111] Tried connecting to [('127.0.0.2', 9042)]. Last error:
> Connection refused\ncassandra.pool: WARNING: Error attempting to reconnect to
> 127.0.0.2, scheduling retry in 16.0 seconds: [Errno 111] Tried connecting to
> [('127.0.0.2', 9042)]. Last error: Connection refused\ncassandra.pool:
> WARNING: Error attempting to reconnect to 127.0.0.2, scheduling retry in 32.0
> seconds: [Errno 111] Tried connecting to [('127.0.0.2', 9042)]. Last error:
> Connection refused\ncassandra.pool: WARNING: Error attempting to reconnect to
> 127.0.0.2, scheduling retry in 64.0 seconds: [Errno 111] Tried connecting to
> [('127.0.0.2', 9042)]. Last error:
[jira] [Created] (CASSANDRA-13655) Range deletes in a CAS batch are ignored
Jeff Jirsa created CASSANDRA-13655: -- Summary: Range deletes in a CAS batch are ignored Key: CASSANDRA-13655 URL: https://issues.apache.org/jira/browse/CASSANDRA-13655 Project: Cassandra Issue Type: Bug Components: CQL Reporter: Jeff Jirsa Assignee: Jeff Jirsa Priority: Critical Fix For: 3.0.x, 3.11.x, 4.x Range deletes in a CAS batch are ignored -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-13654) bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test consistent_range_movement_false_with_rf1_should_succeed_test
[
https://issues.apache.org/jira/browse/CASSANDRA-13654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang resolved CASSANDRA-13654.
--
Resolution: Duplicate
> bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test
> consistent_range_movement_false_with_rf1_should_succeed_test
> --
>
> Key: CASSANDRA-13654
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13654
> Project: Cassandra
> Issue Type: Test
> Components: Streaming and Messaging
> Environment: Branch: trunk
> SHA: f415b736d6cdbfcf71ffeaa4ebbdce406584ad25
>Reporter: ZhaoYang
>Priority: Minor
> Attachments: dtest.log, node3_exception.log
>
>
> The test is unable to find {{Starting listening for CQL clients}} in node3
> which logs following:
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13652) Deadlock in AbstractCommitLogSegmentManager
[
https://issues.apache.org/jira/browse/CASSANDRA-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-13652:
Summary: Deadlock in AbstractCommitLogSegmentManager (was: Deadlock in
AbstractCompactionManager)
> Deadlock in AbstractCommitLogSegmentManager
> ---
>
> Key: CASSANDRA-13652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13652
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Fuud
>
> AbstractCommitLogManager uses LockSupport.(un)park incorreclty. It invokes
> unpark without checking if manager thread was parked in approriate place.
> For example, logging frameworks uses queues and queues uses ReadWriteLock's
> that uses LockSupport. Therefore AbstractCommitLogManager.wakeManager can
> wake thread inside Lock and manager thread will sleep forever at park()
> method (because unpark permit was already consumed inside lock).
> For examle stack traces:
> {code}
> "MigrationStage:1" id=412 state=WAITING
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.cassandra.utils.concurrent.WaitQueue$AbstractSignal.awaitUninterruptibly(WaitQueue.java:279)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.awaitAvailableSegment(AbstractCommitLogSegmentManager.java:263)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.advanceAllocatingFrom(AbstractCommitLogSegmentManager.java:237)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager.forceRecycleAll(AbstractCommitLogSegmentManager.java:279)
> at
> org.apache.cassandra.db.commitlog.CommitLog.forceRecycleAllSegments(CommitLog.java:210)
> at org.apache.cassandra.config.Schema.dropView(Schema.java:708)
> at
> org.apache.cassandra.schema.SchemaKeyspace.lambda$updateKeyspace$23(SchemaKeyspace.java:1361)
> at
> org.apache.cassandra.schema.SchemaKeyspace$$Lambda$382/1123232162.accept(Unknown
> Source)
> at java.util.LinkedHashMap$LinkedValues.forEach(LinkedHashMap.java:608)
> at
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1080)
> at
> org.apache.cassandra.schema.SchemaKeyspace.updateKeyspace(SchemaKeyspace.java:1361)
> at
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1332)
> at
> org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1282)
> - locked java.lang.Class@cc38904
> at
> org.apache.cassandra.db.DefinitionsUpdateVerbHandler$1.runMayThrow(DefinitionsUpdateVerbHandler.java:51)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor$LocalSessionWrapper.run(DebuggableThreadPoolExecutor.java:322)
> at
> com.ringcentral.concurrent.executors.MonitoredRunnable.run(MonitoredRunnable.java:36)
> at MON_R_MigrationStage.run(NamedRunnableFactory.java:67)
> at
> com.ringcentral.concurrent.executors.MonitoredThreadPoolExecutor$MdcAwareRunnable.run(MonitoredThreadPoolExecutor.java:114)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$61/179045.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
> "COMMIT-LOG-ALLOCATOR:1" id=80 state=WAITING
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.cassandra.db.commitlog.AbstractCommitLogSegmentManager$1.runMayThrow(AbstractCommitLogSegmentManager.java:128)
> at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory$$Lambda$61/179045.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Solution is to use Semaphore instead of low-level LockSupport.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-13654) bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test consistent_range_movement_false_with_rf1_should_succeed_test
ZhaoYang created CASSANDRA-13654:
Summary:
bootstrap_test.TestBootstrap.consistent_range_movement_false_with_rf1_should_succeed_test
consistent_range_movement_false_with_rf1_should_succeed_test
Key: CASSANDRA-13654
URL: https://issues.apache.org/jira/browse/CASSANDRA-13654
Project: Cassandra
Issue Type: Test
Components: Streaming and Messaging
Environment: Branch: trunk
SHA: f415b736d6cdbfcf71ffeaa4ebbdce406584ad25
Reporter: ZhaoYang
Priority: Minor
Attachments: dtest.log, node3_exception.log
The test is unable to find {{Starting listening for CQL clients}} in node3
which logs following:
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13653) Create meaningful toString() methods
[
https://issues.apache.org/jira/browse/CASSANDRA-13653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071913#comment-16071913
]
Dave Brosius commented on CASSANDRA-13653:
--
imo,
@Override
public String toString() {
return ToStringBuilder.reflectionToString(this,
ToStringStyle.SHORT_PREFIX_STYLE);
}
can be added as a snippet in your favorite IDE, and you can blow thru lots of
classes, quickly. And does a pretty good job.
> Create meaningful toString() methods
>
>
> Key: CASSANDRA-13653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13653
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Jirsa
>Priority: Trivial
> Labels: lhf, low-hanging-fruit
>
> True low-hanging fruit, good for a first-time contributor:
> There are a lot of classes without meaningful {{toString()}} implementations.
> Some of these would be very nice to have for investigating bug reports.
> Some good places to start:
> - CQL3 statements (UpdateStatement, DeleteStatement, etc), QueryOptions, and
> Restrictions
> Some packages not to worry about:
> - Deep internals that don't already have them
> (org.apache.cassandra.db.rows/partitions/etc)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13653) Create meaningful toString() methods
[
https://issues.apache.org/jira/browse/CASSANDRA-13653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13653:
---
Description:
True low-hanging fruit, good for a first-time contributor:
There are a lot of classes without meaningful {{toString()}} implementations.
Some of these would be very nice to have for investigating bug reports.
Some good places to start:
- CQL3 statements (UpdateStatement, DeleteStatement, etc), QueryOptions, and
Restrictions
Some packages not to worry about:
- Deep internals that don't already have them
(org.apache.cassandra.db.rows/partitions/etc)
was:
True low-hanging fruit, good for a first-time contributor:
There are a lot of classes without meaningful {{toString()}} implementations.
Some of these would be very nice to have for debugging.
> Create meaningful toString() methods
>
>
> Key: CASSANDRA-13653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13653
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Jirsa
>Priority: Trivial
> Labels: lhf, low-hanging-fruit
>
> True low-hanging fruit, good for a first-time contributor:
> There are a lot of classes without meaningful {{toString()}} implementations.
> Some of these would be very nice to have for investigating bug reports.
> Some good places to start:
> - CQL3 statements (UpdateStatement, DeleteStatement, etc), QueryOptions, and
> Restrictions
> Some packages not to worry about:
> - Deep internals that don't already have them
> (org.apache.cassandra.db.rows/partitions/etc)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13653) Create meaningful toString() methods
[
https://issues.apache.org/jira/browse/CASSANDRA-13653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa updated CASSANDRA-13653:
---
Labels: lhf low-hanging-fruit (was: )
> Create meaningful toString() methods
>
>
> Key: CASSANDRA-13653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13653
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Jirsa
>Priority: Trivial
> Labels: lhf, low-hanging-fruit
>
> True low-hanging fruit, good for a first-time contributor:
> There are a lot of classes without meaningful {{toString()}} implementations.
> Some of these would be very nice to have for debugging.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-13653) Create meaningful toString() methods
Jeff Jirsa created CASSANDRA-13653:
--
Summary: Create meaningful toString() methods
Key: CASSANDRA-13653
URL: https://issues.apache.org/jira/browse/CASSANDRA-13653
Project: Cassandra
Issue Type: Bug
Reporter: Jeff Jirsa
Priority: Trivial
True low-hanging fruit, good for a first-time contributor:
There are a lot of classes without meaningful {{toString()}} implementations.
Some of these would be very nice to have for debugging.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13615) Include 'ppc64le' library for sigar-1.6.4.jar
[ https://issues.apache.org/jira/browse/CASSANDRA-13615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071693#comment-16071693 ] Amitkumar Ghatwal commented on CASSANDRA-13615: --- [~jjirsa] - IMO we will need to build against 1.6.4 . if required u could trigger a jenkins job on ppc64le just to validate the above *.so generation . > Include 'ppc64le' library for sigar-1.6.4.jar > - > > Key: CASSANDRA-13615 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13615 > Project: Cassandra > Issue Type: Improvement > Components: Libraries > Environment: # arch > ppc64le >Reporter: Amitkumar Ghatwal > Labels: easyfix > Fix For: 3.0.x, 3.11.x, 4.x > > Attachments: libsigar-ppc64le-linux.so > > > Hi All, > sigar-1.6.4.jar does not include a ppc64le library, so we had to install > libsigar-ppc64le-linux.so.As the community has been inactive for long > (https://github.com/hyperic/sigar), requesting the community to include the > ppc64le library directly here. > Attaching the ppc64le library ( *.so) file to be included under > "/lib/sigar-bin". let me know of issues/dependency if any. > FYI - [~ReiOdaira],[~jjirsa], [~mshuler] > Regards, > Amit -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13639) SSTableLoader always uses hostname to stream files from
[ https://issues.apache.org/jira/browse/CASSANDRA-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Karlsson updated CASSANDRA-13639: - Reproduced In: 2.2.9, 4.0 (was: 2.2.9) Status: Patch Available (was: Open) > SSTableLoader always uses hostname to stream files from > --- > > Key: CASSANDRA-13639 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13639 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Jan Karlsson >Assignee: Jan Karlsson > Fix For: 4.x > > Attachments: 13639-trunk > > > I stumbled upon an issue where SSTableLoader was ignoring our routing by > using the wrong interface to send the SSTables to the other nodes. Looking at > the code, it seems that we are using FBUtilities.getLocalAddress() to fetch > out the hostname, even if the yaml file specifies a different host. I am not > sure why we call this function instead of using the routing by leaving it > blank, perhaps someone could enlighten me. > This behaviour comes from the fact that we use a default created > DatabaseDescriptor which does not set the values for listenAddress and > listenInterface. This causes the aforementioned function to retrieve the > hostname at all times, even if it is not the interface used in the yaml file. > I propose we break out the function that handles listenAddress and > listenInterface and call it so that listenAddress or listenInterface is > getting populated in the DatabaseDescriptor. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-13639) SSTableLoader always uses hostname to stream files from
[ https://issues.apache.org/jira/browse/CASSANDRA-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Karlsson updated CASSANDRA-13639: - Attachment: 13639-trunk Patch on trunk which resolves this issue. Verified it manually with lsof. > SSTableLoader always uses hostname to stream files from > --- > > Key: CASSANDRA-13639 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13639 > Project: Cassandra > Issue Type: Bug > Components: Tools >Reporter: Jan Karlsson >Assignee: Jan Karlsson > Fix For: 4.x > > Attachments: 13639-trunk > > > I stumbled upon an issue where SSTableLoader was ignoring our routing by > using the wrong interface to send the SSTables to the other nodes. Looking at > the code, it seems that we are using FBUtilities.getLocalAddress() to fetch > out the hostname, even if the yaml file specifies a different host. I am not > sure why we call this function instead of using the routing by leaving it > blank, perhaps someone could enlighten me. > This behaviour comes from the fact that we use a default created > DatabaseDescriptor which does not set the values for listenAddress and > listenInterface. This causes the aforementioned function to retrieve the > hostname at all times, even if it is not the interface used in the yaml file. > I propose we break out the function that handles listenAddress and > listenInterface and call it so that listenAddress or listenInterface is > getting populated in the DatabaseDescriptor. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
