Guillaume,
How about the correlation id provide a good starting point for
generating the error report? If we could include all messages in the
in-memory auditor that belong to the same message flow, being able to
see the original request, all transformations and the failing message
exchange in a single report would already be a huge step forward for
troubleshooting, wouldn't it?
Gert
Guillaume Nodet wrote:
It make lots of sense. I really like your idea of a command that
generate an error report. This could prove tremendously usefull if
implemented correctly: I suppose the tricky part will be to determine
what information is usefull and should be included.
The audit is related to Bruce comments too: once you have some
exchanges in memory, being able to easily filter and display those
could be very valuable, provided we can come was an easy enough syntax
for filtering them.
On Tue, Mar 11, 2008 at 1:20 PM, Gert Vanthienen
<[EMAIL PROTECTED]> wrote:
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.
>>
>>
>>
>
>
>
>
