After observing logs of scylla-jmx, I started to notice
the following message:
Running '/bin/journalctl --unit scylla-jmx.service'
[stdout] -- Logs begin at Sat 2016-01-23 10:02:51 UTC, end at Sat 2016-01-23 10:07:26 UTC. --
[stdout] Jan 23 10:05:15 ip-172-30-0-9 systemd[1]: Started Scylla JMX.
[stdout] Jan 23 10:05:15 ip-172-30-0-9 systemd[1]: Starting Scylla JMX...
[stdout] Jan 23 10:05:16 ip-172-30-0-9 scylla-jmx[2685]: Using config file: /etc/scylla/scylla.yaml
[stdout] Jan 23 10:05:22 ip-172-30-0-9 scylla-jmx[2685]: Connecting to http://127.0.0.1:10000
[stdout] Jan 23 10:05:22 ip-172-30-0-9 scylla-jmx[2685]: Starting the JMX server
[stdout] Jan 23 10:05:29 ip-172-30-0-9 scylla-jmx[2685]: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
[stdout] Jan 23 10:05:29 ip-172-30-0-9 scylla-jmx[2685]: SLF4J: Defaulting to no-operation (NOP) logger implementation
[stdout] Jan 23 10:05:29 ip-172-30-0-9 scylla-jmx[2685]: SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
So we're potentially losing a lot of information on our jmx service logs.
Let's update the log4j dependencies, and add the other ones that are
necessary for the logging to work.
Signed-off-by: Lucas Meneghel Rodrigues <lmr@scylladb.com>
Message-Id: <1453746313-15054-1-git-send-email-lmr@scylladb.com>
This patch adds a configuration object to the jmx proxy that support
both the system/command line based properties and it accept a yaml
configuration file. The later options allows the jmx to read scylla
configuration file and connect to it based on this configuration.
The configuration file reader uses a yaml parser that was added to the
pom.xml
If no configuration file is found in the command line, it would look for
SCYLLA_CONF then SCYLLA_HOME then for relative 'conf' directory
Signed-off-by: Amnon Heiman <amnon@scylladb.com>
need merge apiconfig
The API returns errors with an HTTP code 400, 404 or 500 depending on
the cause with a json object that contains the failure reason. The
error message should be populate to the JMX calling client, translated
to the appropriate exception.
This patch adds the ability to detect API failure and throw a runtime
exception with the returned message.
It is up to the calling method what to do with the exception, if it
would do nothing, the calling client would get a RuntimeException,
depends on origin MBean definition, the caller can catch the exception
and throw a specific kind.
Note that any exception that is thrown must be known to the JMX client
or it will not be able to process it.
As a first step, this patch replaces the jersey client to the newer
version under glassfish, which has an easy way of getting a Reply
object, and check its status before returning the results.
The only difference in the method that uses the APIClient is the use of
MultivaluedHashMap.
The following MBean implementation where changed
ColumnFamily
CompactionManager
Gossiper
EndpointSnitchInfo
CacheService
StorageProxy
StorageService
Signed-off-by: Amnon Heiman <amnon@scylladb.com>
From Amnon:
"This series adopt the yammer Metric library to use with out API. The
library it self is taken as is by adding it to the Maven dependency. The
required adaptation is that information will not be added in push to the
library Metric, instead, when required, the specific Metric would use
the APIClient to fetch information from the system using the API.
This approach would mean that there will be little adaptation when code
would be passed from origin."
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Conflicts:
pom.xml
This adds the functionality that is used by the JMX from Origin.
The following files where import: FileUtils.java Pair.java
SnapshotDetailsTabularData.java, un needed functionality was removed to
minimize the dependency and they were placed in a util directory.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
This adds the dependency for the yammer counter library and for the
google collection that are used with it.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
The urchin files (Client and Main) where moved to:
com.cloudius.urchin.api and com.cloudius.urchin.main respectively.
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>
This adds the java project that expose the system MBean.
The Main would start any required classes and would wait forever.
The mvn creates jar with main and set the classpath accordingly.
To start do:
java -jar target/urchin-mbean-1.0.jar
Signed-off-by: Amnon Heiman <amnon@cloudius-systems.com>
