Right, coupled with a few more informations (list of existing endpoints, system informations, state of JBI artifacts and OSGi bundles), we should have a clear idea about what's happening. We could even include few lines of the last log entries using the log command (SMX4KNL-1), and maybe an optional thread dump.
On Tue, Mar 11, 2008 at 2:04 PM, Gert Vanthienen <[EMAIL PROTECTED]> wrote: > 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. > >> >> > >> >> > >> >> > >> > > >> > > >> > > >> > > >> > >> > >> > > > > > > > > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
