Displaying #cassandra-dev/2017-09-04.log:

Mon Sep 4 03:51:45 2017  jeffj:Joined the channel
Mon Sep 4 05:13:50 2017  jeffj:Joined the channel
Mon Sep 4 07:03:18 2017  spodkowinski:Joined the channel
Mon Sep 4 07:14:58 2017  nyavin:Joined the channel
Mon Sep 4 07:16:04 2017  nyavin:developing a java app which collects data from Cassandra cluster.
Mon Sep 4 07:16:55 2017  nyavin:while searching I found each cassandra server knows about all other servers within the same cluster, but they cannot tell what jmx port is used by each server. why is that?
Mon Sep 4 07:26:02 2017  hkroger:nyavin: Check #cassandra channel for support. This channel is for development of the cassandra itself.
Mon Sep 4 07:27:25 2017  jeffj:Joined the channel
Mon Sep 4 07:29:27 2017  nyavin:I am talking about developing java apps for this. or possibly file an idea of extending the MBean of cassandra
Mon Sep 4 07:31:01 2017  nyavin:hkroger: but of course I will check there per your suggestion, thank you
Mon Sep 4 07:56:11 2017  hkroger:nyavin: ah, right
Mon Sep 4 07:56:14 2017  hkroger:sorry
Mon Sep 4 09:10:19 2017  kvaster:Joined the channel
Mon Sep 4 09:28:54 2017  jeffj:Joined the channel
Mon Sep 4 09:50:08 2017  krut:nyavin: the nodes don't need to know about each others JMX ports. JMX is only used as a client interface (nodetool). internode communications have their own protocol
Mon Sep 4 10:07:12 2017  Guest73:Joined the channel
Mon Sep 4 10:12:14 2017  hkroger:But it's true that this sort of configuration info would be good to be available to support 3rd party tools
Mon Sep 4 10:45:15 2017  krut:yeah, i can see that
Mon Sep 4 10:55:38 2017  Eric:Joined the channel
Mon Sep 4 10:57:15 2017  ehubert:Joined the channel
Mon Sep 4 11:02:20 2017  ehubert:Hi Cassandra-Devs! Before creating a Jira ticket proposing a change I would like to ask for your feedback.
Mon Sep 4 11:02:46 2017  ehubert:After upgrading from Cassandra 3.9 to 3.11.0 we are facing an issue using Cassandra embedded in integration tests. This is because our application uses a different logging backend and so far we simply excluded all logback dependencies. With Cassandra 3.11.0 the server does not startup because of direct code dependencies to logback-core and logback-classic.
Mon Sep 4 11:04:05 2017  ehubert:For reference: CASSANDRA-12509 adds ch.qos.logback.core.hook.DelayingShutdownHook in StorageService#initServer() and CASSANDRA-12535 adds SMAwareReconfigureOnChangeFilter in org.apache.cassandra.cql3.functions.ThreadAwareSecurityManager.install() using multiple logback internals.
Mon Sep 4 11:04:06 2017  CassBotJr:https://issues.apache.org/jira/browse/CASSANDRA-12535 (Resolved; Fixed; 3.0.11, 3.10): "Prevent reloading of logback.xml from UDF sandbox"
Mon Sep 4 11:04:06 2017  CassBotJr:https://issues.apache.org/jira/browse/CASSANDRA-12509 (Resolved; Fixed; 3.0.10, 3.10): "Shutdown process triggered twice during if the node is drained"
Mon Sep 4 11:06:02 2017  ehubert:My question is whether it would be desirable to only execute this code, if logback is available (using reflection) or whether you see some other (maybe even simpler) alternative.
Mon Sep 4 11:09:14 2017  spodkowinski:ehubert: see #13396 for related discussion
Mon Sep 4 11:09:15 2017  CassBotJr:https://issues.apache.org/jira/browse/CASSANDRA-13396 (Patch Available; Unresolved; Unscheduled): "Cassandra 3.10: ClassCastException in ThreadAwareSecurityManager"
Mon Sep 4 11:16:11 2017  ehubert:Thanks for this pointer - I go through the discussion trying to skip all the less constructive blaming. ;-)
Mon Sep 4 11:18:18 2017  kvaster_:Joined the channel
Mon Sep 4 11:44:41 2017  ehubert:I went through the ticket and it looks like the reporters had two logging implementations on their classpath (logback from cassandra and another one) and SL4J picked the other one. If there is no logback on the classpath, one will receive different errors and ThreadAwareSecurityManager will be only one place, while another will be StorageService#initServer() .
Mon Sep 4 11:45:26 2017  ehubert:Based on the available discussion I'm not sure whether an alternative approach using relection would be considered, but I guess the best is to comment directly on the open ticket. Thanks again for the pointer!
Mon Sep 4 14:43:41 2017  jshook:Joined the channel
Mon Sep 4 15:04:14 2017  nyavin:as an idea I would store the JMX port within an MBean attribute. then later use Docker containers to spawn off cassandra instances, such that all their ports are known across the cluster. Spawning a container can even be with Apache oozie or puppet. Still the need remains to be able to figure out which ports are already allocated across one node or event Rack
Mon Sep 4 15:30:49 2017  jeffj:Joined the channel
Mon Sep 4 18:04:36 2017  Guest73:Joined the channel
Mon Sep 4 18:14:08 2017  JayZhuang:Joined the channel
Mon Sep 4 18:30:07 2017  zsmithnyc_:Joined the channel
Mon Sep 4 18:56:41 2017  kvaster_:Joined the channel
Mon Sep 4 20:32:30 2017  kvaster:Joined the channel
Mon Sep 4 21:20:49 2017  echoreply:Joined the channel
Mon Sep 4 22:50:22 2017  jeffj:Joined the channel