Histograms startTimeStamp not being set

[alcarraz]

Hi all,

I'm trying something new here, instead of filling an issue, because this potentially is not, starting a discussion.

This wouldn't be an issue, and it hasn't been until now, if it weren't because of some strange behavior when a long has the MAX_VALUE value in Elasticsearch. I know there are other workarounds I can perform, for instance putting a custom mapper in the qrest transaction manager context, .

Anyway, the Metrics class is not setting the startTimeStamp on the histograms and I figure it could be a useful information to have in the histogram object, I see two options here.

1. In getHistogram always set the startTimeStamp to current time millis.
   

   jPOS/jpos/src/main/java/org/jpos/util/Metrics.java

   Lines 59 to 68 in 442aef8

   	private Histogram getHistogram (String p) {
   	Histogram h = metrics.get(p);
   	if (h == null) {
   	Histogram hist = new Histogram(template);
   	hist.setTag(p);
   	metrics.putIfAbsent(p, hist);
   	h = metrics.get(p);
   	}
   	return h;
   	}

2. Set the startTimeStamp on the template on the Metrics constructor if it is not previously set (in case the caller has some reason for that).

I'm inclined to option 2 if this is implemented.

Any thoughts? If agreed I can perform a PR with the implementation.

[alcarraz]

I've just realized that the Metric class references the Histogram class that doesn't have the startTimeStamp getters and setters. So this should be done at Metrics instantiation time, e.g., in QMUX, TransactionManager, etc., unless we do it if the template is an instance of AbstractHistogram.

This makes this a not so good idea. It might still be useful, but unsure it is worth the extra code from the point of view of the project. That said, if this could be an accepted addition, I'm still willing to implement it. I already went the workaround route in my case.

[ar]

What is the exception/problem you're getting in ES when startTimeStamp isn't set?

[alcarraz]

For some reason, the value that reaches ES is 9223372036854775808 instead of 9223372036854775807, I was trying to create a runtime field and the script kept failing with:

Numeric value (9223372036854776000) out of range of long

even though I wasn't even accessing that field, here apparently due to javascript issues the number was even being rounded up.

This is not an issue anymore for me, since I took the workaround to ignore that field. And I probably won't use the runtime field.

This is the participant with a quick and dirty workaround, just in case someone has this issue in the future:

public class IgnoreStartTimeStampAttribute extends TxnSupport {
    private static final ObjectMapper MAPPER = Mapper.getMapper();
    
    static {
        MAPPER.addMixIn(AbstractHistogram.class, MixIn.class);
    }
    @Override
    public int prepare(long id, Serializable context) {
        ((Context)context).put(SendResponse.MAPPER, MAPPER);
        return PREPARED | NO_JOIN;
    }
}

@SuppressWarnings("unused")
abstract class MixIn {
    @JsonIgnore abstract long getStartTimeStamp();
}

I am trying to use logstash to consume http://localhost:8081/q2. The other issue I'm having in kibana is with the arrays of objects, i.e., txnmgr and mux. For that, I will have to filter them and convert them into a hash by their names.

[ar]

Sorry I don't understand your use case. I don't understand when you say "For some reason, the value that reaches ES is ..." how that value gets injected into LogStash/ES.

If you want to propose a non breaking PR to the Metrics class, I'm fine evaluating.

[alcarraz]

It is injected by a logstash pipeline with an httppoller like this:

input {
  http_poller {
    urls => {
      q2 => "http://${JPOS_HOST}:${QREST_PORT}/q2"
#      muxes => "http://${JPOS_HOST}:${QREST_PORT}/q2/mux"
    }
    request_timeout => 60
    # Supports "cron", "every", "at" and "in" schedules by rufus scheduler
    # schedule => { cron => "* * * * * UTC"}
    schedule => { "every" => "30s"}
    codec => "json"
    # A hash of request metadata info (timing, response headers, etc.) will be sent here
    metadata_target => "http_poller_metadata"
  }
}

This is a proof of concept right now, based on this post by @andresantoniuk. I'm planning to add other endpoints to query more specific status, like info about channels and servers. Maybe they could be added to QInfo as well or not.

Given what I said earlier, I no longer have a clear reason to take a specific action on this, unless someone could find it useful. I think it might make sense to add that info to the Histogram but since is not a property exposed through the Histogram class, it should be set by the callers that create the templates.
The Metrics class could do something by checking if the template is an instance of AbstractHistogram. But I'm not sure if it's worth it, so if no one else sees an aggregated value on that, it wouldn't make much sense to take action.

[ar]

The Metrics class could do something by checking if the template is an instance of AbstractHistogram. But I'm not sure if it's worth it, so if no one else sees an aggregated value on that, it wouldn't make much sense to take action.

If adding the start date on AbstractHistogram instances makes sense, because this is something that just happens at startup time, I think it's good info to have. Feel free to send a PR if you find it useful.