This release adds a new message bus stat to capture the time spent in a message bus provider's send call when sending messages.

Prior to this change, the message latency stats stopped at the point just before a message is written to the wire. This was because message latency stats were designed to cover the portion of time spent in the platform and provider specific send time was considered to be external. However, in the case that a provider blocks in flow control or is otherwise slow, the provider send time may have an impact on the sending thread's throughput making the time spent writing to the wire of interest from a platform statistic standpoint. This story implements capturing the post wire send timestamp and reports the delta between preWireTs and this timestamp as wire send time. This new latency stat is reported in engine stats output with other bus stats as 'ws' for wire send times and in hearbeats as WireSendLatencies.

*Sample of printed output*

...[ ws] [sample=65536, min=7 max=54 mean=10 median=11 75%ile=11 90%ile=13 99%ile=19 99.9%ile=23 99.99%ile=26]
......NewOrder...[ ws] [sample=0, min=-1 max=-1 mean=-1 median=-1 75%ile=-1 90%ile=-1 99%ile=-1 99.9%ile=-1 99.99%ile=-1]
......OrderEvent...[ ws] [sample=65536, min=7 max=24 mean=8 median=8 75%ile=9 90%ile=12 99%ile=15 99.9%ile=19 99.99%ile=22]

These latencies are also emitted in heartbeats.

See Also:
* ISrvMonAppBusBindingStats.html.getWireSendLatencies()

This release improves the trace of an engine's config to include channel details when engine config trace is enabled.

<1,24578,perf4> 20161213-01:47:01:495 (cfg)...
Engine 'market' Configuration {
...state_factories=[]
...message_factories=[]
...channels
......xsim-morders@market [join=true]
.........Id     : 1
.........Key    : orders/${Region}
.........Filter : null
.........QoS    : Guaranteed
......xsim-mconfirm@market [join=false]
.........Id     : 2
.........Key    : null
.........Filter : null
.........QoS    : Guaranteed

This release adds inbound and outbound message logger stats to heartbeats and stats trace:

[Inbound Message Logger]
<No Inbound Message Logger>

[Outbound Message Logger]
Put {0(0 0)} Updates {0(0 0)} Removes {0(0 0)} Sends {979,561(0 11,000)} Commits {534,306(0 6,000)} Forks {0(0 0)}
Disruptor (SingleThreaded, BusySpin) {[0 of 1,024] 0%}
...[o2p] [sample=65536, min=0 max=93 mean=26 median=26 75%ile=45 90%ile=51 99%ile=57 99.9%ile=64 99.99%ile=78]
Writer {qsize=0}

These stats are emitted in server heartbeats as part of engine stats.

See Also:

• ISrvMonAppEngineStats.getOutboundMessageLoggerStats()
• ISrvMonAppEngineStats.getInboundMessageLoggerStats()

This release changes the StatsDumpTool to filter admin app stats by default when generating stats trace from hearbeat logs. Admin app stats can still be done by passing the '-a' flag to the tool.

This release enhances the StatsDumpTool to allow accept the start and end time options in the same time formats accepted by transaction log tool queries. For example, one can now launch the tool with a time range such as:

java -cp "libs/*" com.neeve.tools.StatsDumpTool -s "30 minutes ago" -e "20 minutes ago" rdat/server-hearbeats/myapp-heartbeats.log

java -cp "libs/*" com.neeve.tools.StatsDumpTool -s 2:00pm -e 2:05pm rdat/server-hearbeats/myapp-heartbeats.log

It is still possible to specify these arguments in the prior timestamp format such as:

java -cp "libs/*" com.neeve.tools.StatsDumpTool -s "20161216-02:06:00" rdat/server-hearbeats/myapp-heartbeats.log

These release now populates the o2p stats in store persister and icr sender stats emitted in heartbeats on the SrvMonDisruptorStats entity.

This release fixes the the StatsDumpTool to correctly display the stores Commit Queue Size (cqs) stats.
Compatibility Notes:

This release fixes the the StatsDumpTool to correctly display the store's Commit Queue Size (cqs) stats. Prior to this fix this stat was erroneously displaying the values for a store commit latencies

This release fixes a performance regression that can occur in detached outbound message logging. The regression was caused by the movement of some of the serialization logic for outbound message metadata to be done by the aep engine's thread along with the dispose call for the message being logged. The additional logic in the aep engine's thread can cause reduced throughput for applications that have heavy outbound message loads and are close to be cpu bound on the business logic thread.