Guillaume,
Personally, I find myself using the logging to track down issues most of
the time as well. Very rarely, I have to rely on remote debugging to
really see the thing going astray step by step. If we would really want
to make this debug flow useful, it would require quite a few features
and I'm not sure this is the right time to invest that amount of time --
there still is a lot of other work to be done with more benefit for the
users in my mind.
On the other hand, I think we could invest some time in improving the
possibilities for logging/auditing problematic message exchanges (or
entire 'flows' by looking at the correlation id). I'm thinking of
- console commands to enable on-the-fly auditing (based on message
properties, exceptions being thrown, ...) to isolate the message
exchanges that have gone wrong
- a command to create an error report (with useful information such as
thread dumps, errors in messages, a subset of the log messages belonging
to the same message flow, ...) -- could also be useful if we want them
to provide more information on the mailing list
Gert
Guillaume Nodet wrote:
I've created the following JIRA issue for ServiceMix NMR.
Do you think it's worth doing it ? Would it help people finding
problems ? I usually use the log file, but having something more
dynamic may be helpful.
On Tue, Mar 11, 2008 at 10:36 AM, Guillaume Nodet (JIRA)
<[EMAIL PROTECTED]> wrote:
Debugging flows
---------------
Key: SMX4NMR-21
URL: https://issues.apache.org/activemq/browse/SMX4NMR-21
Project: ServiceMix NMR
Issue Type: New Feature
Reporter: Guillaume Nodet
Create a set of console commands / OSGi service / NMR listeners to be able to:
* add / remove / disable breakpoints (with conditional evaluation on
exchanges)
* list paused exchanges
* inspect / modify a paused exchange
* resume execution for a exchange
A breakpoint is basically a condition that filters an exchange. If the filter
match, the breakpoint is activated and the flow for the given exchange is
paused. Simple breakpoints include:
* exchanges originated from a given endpoint
* exchanges targeted at a given endpoint
* exchanges in an ERROR status
* ...
Using an ExchangeListener, it should be easy to intercept all the exchanges.
I think the problem is that currently, the only way is to suspend the calling
thread and wait for a signal that would be set by a command when resuming an
exchange. This is not really scalable. Maybe using a flow is a better
option, but I think it would be more intrusive, so that entering / exiting
debug mode may not be easy.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
