virgo47 / javasimon Goto Github PK

For generic JMX access to simon attributes I'm using the next classes

public class MonitorStopwatchMXBeanImpl extends StopwatchMXBeanImpl implements MonitorStopwatchMXBean {

    public MonitorStopwatchMXBeanImpl(Stopwatch stopwatch) {
        super(stopwatch);
    }

    /**
     * {@inheritDoc}
     */
    @Override
    public List<String[]> getAttributes() {
        List<String[]> attributes = new ArrayList<String[]>();
        Iterator<String> iterator = simon().getAttributeNames();
        while (iterator.hasNext()) {
            String key = iterator.next();
            Object attr = simon().getAttribute(key);
            String value = attr != null ? String.valueOf(attr) : null;
            String[] attrib = new String[2];
            attrib[0] = key;
            attrib[1] = value;
            attributes.add(attrib);
        }
        return attributes;
    }
}

public class MonitorCounterMXBeanImpl extends CounterMXBeanImpl implements MonitorCounterMXBean {

    public MonitorCounterMXBeanImpl(Counter counter) {
        super(counter);
    }

    /**
     * {@inheritDoc}
     */
    @Override
    public List<String[]> getAttributes() {
        List<String[]> attributes = new ArrayList<String[]>();
        Iterator<String> iterator = simon().getAttributeNames();
        while (iterator.hasNext()) {
            String key = iterator.next();
            Object attr = simon().getAttribute(key);
            String value = attr != null ? String.valueOf(attr) : null;
            String[] attrib = new String[2];
            attrib[0] = key;
            attrib[1] = value;
            attributes.add(attrib);
        }
        return attributes;
    }

As a side effect I must extend also MonitorJmxRegisterCallback. Much convenient sollution is to have these methods in StopwatchMXBeanImpl and CounterMXBeanImpl

Originally from https://code.google.com/p/javasimon/issues/detail?id=126

Works like sampleIncrement, but merely reads the value for the provided incremental sample key, does not reset it. Is implemented on Simon, that is both for Stopwatch and Counter.

I opened the problem here and in google code just in case....

What steps will reproduce the problem?

1. Started 10 threads, each thread loops the following:
   a) Split s = SimonManager.getStopwatch("TEMP").start();
   b) s.stop("" + r.nextInt(2)); //where r is java.util.Random to produce a subSimon of name "0" or "1"
2. Started 1 thread that loops the following:
   a) System.out.println(org.javasimon.utils.SimonUtils.simonTreeString(SimonManager.getRootSimon()));
   b) SimonManager.clear();
   c) Thread.sleep(1000);
3. The threads started in step #1 end up deadlocking.

What is the expected output? What do you see instead?
Expect this application to run without deadlocking.

What version of the product are you using? On what operating system?
javasimon-core-4.0.1
I have run this on both MAC OS X and z/OS both result in the same problem.

Please provide any additional information below.
Two observations:

1. When Split.stop(String subSimon) only uses a single subSimon name the deadlock doesn't appear to occur, only when two or more subSimon names are used.
2. When SimonManager.clear() is not issued the deadlock doesn't appear to occur

I have provided two files:

1. My test cases that can recreate the problem. https://code.google.com/p/javasimon/issues/attachmentText?id=130&aid=1300000000&name=SimonThreadTest.java&token=ABZ6GAeoOzda3g7AfVZ5xlNyDUMwLkswqQ%3A1419892900998
2. A thread dump showing the blocked threads and the stack trace of where they are blocked.
   https://code.google.com/p/javasimon/issues/attachmentText?id=130&aid=1300000001&name=thread+dump.txt&token=ABZ6GAdYWGNdlPijB8WNpGTszOa9AI_7FA%3A1419892900998

The "Current version: 4.1.3 (May 2017, requires Java 7)" javadoc link points to http://virgo47.github.io/javasimon/api/4.1/ which gives Github 404.

org.javasimon.console.json.JsonStringifierFactory currently escapes the following characters:

"\"" => "\\\""
"\\" =>  "\\\\"
"/" => "\\/"

But there are also some characters that require escaping:

"\b" => "\\b"
"\n" => "\\n"
"\t" => "\\t"
"\f" => "\\f"
"\r" => "\\r"

Otherwise console is not working if a simon note contains a new line character:

Hi, I've a class hierarchy like this (semplified)

interface Interface {
  @Monitored
  public run() {...}
}

class Class1 implements Interface {
  public run() {...}
}

class Class2 implements Interface {
  public run() {...}
}

The stopwatch uses as name the first class of which run method was invoked and then all invocations of run methods in both classes are traced with the same name and this is wrong.

Example :

2015-07-29 12:08:34,976 DEBUG [Stopwatch] Split 1.03 s in Stopwatch Simon Stopwatch: total 879 s, counter 146, max 30.1 s, min 113 ms, mean 6.02 s [Class1.run INHERIT "Class1.run"]
because after the startup of the application I called Class1 run method first.

If I restart the application and call run method of Class2 before Class1, the Stopwatch will log :

2015-07-29 12:08:34,976 DEBUG [Stopwatch] Split 1.03 s in Stopwatch Simon Stopwatch: total 879 s, counter 146, max 30.1 s, min 113 ms, mean 6.02 s [Class2.run INHERIT "Class2.run"]

and all stopwatch for both run methods will be added together.

Obviously I can move the annotation to Class1 and Class2 run methods, but is it possible to solve this problem in order to avoid to write the annotation in every implementation of the interface?
Perhaps the problem is in how the CachedStopWatchSource use the location (interface method instead of target class method)?

Or, at least, the stopwatch should use the interface name + method name in order to not show misleading counters.

When using the javasimon JDBC driver to obtain JDBC performance profiling I've found that the SqlNormalizer is using excessive CPU, to the point that it is noticeably affecting the performance itself.

I am using Hibernate as the ORM library which already formats SQL in a consistent pattern. Can an option be added to the Javasimon JDBC Driver that disables SQL normalisation?

Below is a snippet from a thread dump showing a stacktrace containing the SqlNormalizer. CPU sampling using JVisualVM also showed that the SqlNormaliser was a CPU hog.

"pool-8-thread-1" prio=6 tid=0x000000001a0d4000 nid=0x1ec0 runnable [0x0000000022a4b000]
   java.lang.Thread.State: RUNNABLE
        at java.util.Arrays.copyOf(Unknown Source)
        at java.lang.AbstractStringBuilder.expandCapacity(Unknown Source)
        at java.lang.AbstractStringBuilder.ensureCapacityInternal(Unknown Source)
        at java.lang.AbstractStringBuilder.append(Unknown Source)
        at java.lang.StringBuffer.append(Unknown Source)
        - locked <0x000000009ce39ec0> (a java.lang.StringBuffer)
        at java.util.regex.Matcher.appendReplacement(Unknown Source)
        at java.util.regex.Matcher.replaceAll(Unknown Source)
        at org.javasimon.utils.Replacer.process(Replacer.java:88)
        at org.javasimon.jdbc4.SqlNormalizer.applyReplacers(SqlNormalizer.java:114)
        at org.javasimon.jdbc4.SqlNormalizer.normalize(SqlNormalizer.java:97)
        at org.javasimon.jdbc4.SqlNormalizer.<init>(SqlNormalizer.java:78)
        at org.javasimon.jdbc4.SimonStatement.prepare(SimonStatement.java:122)
        at org.javasimon.jdbc4.SimonStatement.executeBatch(SimonStatement.java:346)
        at com.jolbox.bonecp.StatementHandle.executeBatch(StatementHandle.java:424)
        at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:70)
        at org.hibernate.jdbc.BatchingBatcher.addToBatch(BatchingBatcher.java:56)

Originally from: https://code.google.com/p/javasimon/issues/detail?id=125

Hi,

I use Javasimon in Spark+Drools application, and get undeterministic responses,
some measurements are losts and not written to output.

Could I ask class AbstractSimon should be thread-safe ?
If yes, please change incrementalSimons from HashMap to java.util.concurrent.ConcurrentHashMap.

thanks

vlk

The javasimon console includes an old version (1.8.2) of jQuery which is vulnerable to Cross-site Scripting (XSS) attacks.

for details see:

• https://nvd.nist.gov/vuln/detail/CVE-2012-6708
• https://nvd.nist.gov/vuln/detail/CVE-2015-9251

This method is frequently called, each time a Stopwatch is requested, the threads will be blocked here. Can we narrow the scope of the lock? E,g. only lock the whole manager when allSimons.get(name) returns null.

private Simon getOrCreateSimon(String name, Class<? extends AbstractSimon> simonClass) {
    if (name == null) {
        // create an "anonymous" Simon - Manager does not care about it anymore
        return instantiateSimon(null, simonClass);
    }
    if (name.equals(ROOT_SIMON_NAME)) {
        throw new SimonException("Root Simon cannot be replaced or recreated!");
    }
    AbstractSimon simon = allSimons.get(name);
    if (simon != null && simonClass.isInstance(simon)) {
        return simon;
    } else {
        synchronized (this) {
            ...........
        }
    }
    callback.onSimonCreated(simon);
    return simon;
}

Or can we use a StampLock or ReadWriteLock for this?

Have run into a CME in ManagerConfiguration.getConfig()
The configs (LinkedHashMap) is apparently updated by processSimon() while getConfig() is looping over the keyset

Hi all,
I'm working through an old project I need to update, and have come across code of the ilk

SimonManager.getSimon(name).reset();

I see the reset() method exists in 2.4, but is disappeared in 2.5, with no deprecation warning or advice on what replaces it that I can find.

can anyone advise for modern Simon what should replace this reset() functionality?

cheers

and it's being referenced

In the 4.1.2 snapshot It appears that the version of the jackson library (2.0.4) provided under the demoapp is incompatible with the recently updated spring version ( 4.1.6.RELEASE). This results in the stack trace below when you try to create new item in the demo. spring 4.1.6 was compiled against jackson 2.5.4 and that at least resolves this issue.

java.lang.NoSuchMethodError: com.fasterxml.jackson.databind.ObjectMapper.getFactory()Lcom/fasterxml/jackson/core/JsonFactory;
at org.springframework.http.converter.json.AbstractJackson2HttpMessageConverter.writeInternal(AbstractJackson2HttpMessageConverter.java:217)
at org.springframework.http.converter.AbstractHttpMessageConverter.write(AbstractHttpMessageConverter.java:208)

Please consider adding a proxy JDBC driver for version 4.2 (which is shipped with Java 8)

As I reported in https://code.google.com/p/javasimon/issues/detail?id=21 a few years ago, JavaSimon was reporting some very large total split time numbers when operating in an environment with lots of threads contending for the same timer.

This still appears to be the case with version 3.5.2.

You can see the relevant test in my BasicMon project here: https://github.com/rocketraman/basicmon/blob/master/src/test/java/org/basicmon/benchmark/CriticalSectionTimerComparison.java

Some sample output from the above class:

Result: BasicTimer: [CriticalSection] total 41.7 ms, count 1200000, mean 34 ns, active 0, active mean 7.99
Test BasicTimer Sync Total: 220 ms

Result: Simon Stopwatch: total 1.51 s, counter 1200000, max 8.91 ms, min 56 ns, mean 1.26 us [CriticalSection INHERIT], mean 1.26 us, active max 12
Test Simon Total: 291 ms

You can see that even with only one thread per CPU, and with the block being timed being completely empty, BasicMon reported an average of 34 ns inside the empty timed block for a total time of 41.7 ms over the 1.2M iterations.

In contrast, Simon reports a mean of 1.26 us inside the empty timed block, for a total of 1.51s spent doing absolutely nothing (36 times longer than BasicMon for the same test).

The numbers become even worse as the thread count is increased.

For sanity and easy building of 3.5 I'm dropping JDBC 4.1 module (that is javasimon-jdbc41 artifact) from this branch. If you need JDBC 4.1, go for Java Simon version 4.x.

I have an HTTP request simon com.github.raipc.items.with%20space. When I press Refresh in Detail View i get the following error.

org.javasimon.console.ActionException: Simon "com.github.raipc.items.with space" not found
	at org.javasimon.console.action.DetailJsonAction.execute(DetailJsonAction.java:47)
	at org.javasimon.console.SimonConsoleRequestProcessor.processContext(SimonConsoleRequestProcessor.java:236)
	at org.javasimon.console.SimonConsoleRequestProcessor.processRequest(SimonConsoleRequestProcessor.java:213)
	at org.javasimon.console.SimonConsoleServlet.doGet(SimonConsoleServlet.java:77)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1655)
...

I found an opposite issue that was fixed by decoding values. Probably jetty and weblogic HttpServletRequest.getParameter implementations differ, so I would postpone URL-decoding.