I think you need to consider having a special logger that logs the required information - turning on TRACE for everything will have too big an impact. Feel free to take a look at the IronJacamar tracer module.

Jesper Pedersen wrote:

 

I think you need to consider having a special logger that logs the required information - turning on TRACE for everything will have too big an impact. Feel free to take a look at the IronJacamar tracer module.

What's the tracer module. Is it:

- akin to a dedicated logging level (and would we have to update all of relevant trace lines that the NTA tool needs);

- a byte code manipulator that injects log lines into the code;

- ...

I agree that TRACE logging is not ideal. However it has these advantages:

1) It works with already released products. We want to use NTA today, so it needs to work with what our customers are using.

2) It's easy for GSS to ask for a TRACE log from customers.

Going forward, I think we need a more optimal process. For example, the events are sent directly to NTA and kept in memory. NTA can then export this data as a binary dump, to add to be added to a support case.

I have said for a while we should develop our own log4j appender that intercepts the log messages, processes them and then writes them to the DB (maybe via some UDP transport on a different server?).  I think that should perform as well as any other technique and prevents the intermediary log file being written. The first thing it can do is drop message codes it knows nothing about.

Tom,

Yes I agree that would probably be the implementation route we'd want to go down. But it will only work for new releases, which will take a while to filter through the community.

Paul Robinson wrote:

 

Tom,

 

Yes I agree that would probably be the implementation route we'd want to go down. But it will only work for new releases, which will take a while to filter through the community.

But the longer you wait to do it the more releases it won't be available in - if I was on the team I would bite the bullet and apply the JDFI methodology.

When looking at concrete things we can do. There are a few options:

1. Pick some features we think are blockers

2. Find some blockers that affect our community

I think it would be useful to look at how much of a limiting factor we gauge the performance to be.raggz and jolee might have some input on that?

The IronJacamar tracer is a dedicated module that logs at a special TRACE category in a machine readable format, e.g. tools are needed to make it human readable. Currently there is no need to keep the event information in memory, as the tracer is used to track down ConnectionEventListener error scenarios.

Read more here: http://www.ironjacamar.org/doc/roadto12/tracer.html

My use cases are normally after the fact analysis,  but this is based upon TRACE logging having been captured.  So,  currently I don't have performance concerns relating to use of the tool.  I wouldn't recommend using in PROD,  based upon the same rationale that I wouldn't recommend TRACE logging to be left on in PROD.

Thanks, that makes sense to me.

.Tom Ross raised  [NTA-74] Please add progress bar - JBoss Issue Tracker  so it may be still be an issue

You may be interested in [JBJCA-1214] XAResource statistics, which adds XAResource statistics at a pool level, if <wrap-xaresource> is true (default). Could be used to display simple values in the web console (through DMR calls to the statistics nodes)