Switch from JCL to EurekaLog

[Berocoder 24]

My team maintains a big multiuser application. Biggest customer has about 200 users. Callstacks from exceptions is generated with JCL and logged to a text-file for each session together with other kind of loggings.
Now we have idea to switch to EurekaLog instead as we have some strange random exceptions. Probably wrong memoryhandling.

Any advice for a good plan for this ?
Currently we have tools that parse the log-files to read exceptions and add it to a datebase.
Then we can view list of most common exceptions. List of most common callstacks etc

EurekaLog has its own logviewer and database but it is completely different.
Not sure how well that works with the huge amount of data we have.

 

Can we have maybe logging to both old format and new format?

Comments appreciated 😊

Edited December 10 by Berocoder

[Cristian Peța 107]

2 hours ago, Berocoder said:

EurekaLog has its own logviewer and database but it is completely different.
Not sure how well that works with the huge amount of data we have.

EurekaLog can send data to a bug tracker. See https://www.eurekalog.com/help/eurekalog/index.php?bug_trackers_setup.php

We use MadExcept and data are sent to Mantis that uses MySQL (actually MariaDB). An SQL server can handle a huge amount of data.

 

[Anders Melander 1813]

5 hours ago, Berocoder said:

the huge amount of data we have.

It sounds to me like you have a quality problem if you have that many exceptions.

 

In the applications that I work on (users in the hundreds), every single exception that are caught by the outer exception handler (madExcept in our case) is treated as a must-fix bug. On the average I would say we get one or two a month if we've been sloppy with the QA.

The madExcept bug reports are usually either mailed to us by the madExcept UI, or retrieved from the customer's system by our supporters, and attached to a JIRA issue. It is extremely rare that we need to compare call stacks to detect a duplicate. AFAIK madExcept can do so automatically via a hash or something but we've never used that feature.

 

So the only advice I can offer is: fix your bugs before release 😉 

[Brian Evans 109]

4 hours ago, Anders Melander said:

It sounds to me like you have a quality problem if you have that many exceptions.

 

In the applications that I work on (users in the hundreds), every single exception that are caught by the outer exception handler (madExcept in our case) is treated as a must-fix bug. On the average I would say we get one or two a month if we've been sloppy with the QA.

The madExcept bug reports are usually either mailed to us by the madExcept UI, or retrieved from the customer's system by our supporters, and attached to a JIRA issue. It is extremely rare that we need to compare call stacks to detect a duplicate. AFAIK madExcept can do so automatically via a hash or something but we've never used that feature.

 

So the only advice I can offer is: fix your bugs before release 😉 

Could just be logging the stacks of exceptions that are handled and logging them as part of seeing what errors users hit most often. Of limited use but have seen it done - like graying out invalid choices + hint of why on mouse over or click instead of letting the user select an item and then producing an error dialog/message latter on that users are hitting far too often. 

[Anders Melander 1813]

Stack tracing is very expensive and not all exceptions are errors.

[MichaelT 6]

12 hours ago, Anders Melander said:

It sounds to me like you have a quality problem if you have that many exceptions.

 

In the applications that I work on (users in the hundreds), every single exception that are caught by the outer exception handler (madExcept in our case) is treated as a must-fix bug. On the average I would say we get one or two a month if we've been sloppy with the QA.

The madExcept bug reports are usually either mailed to us by the madExcept UI, or retrieved from the customer's system by our supporters, and attached to a JIRA issue. It is extremely rare that we need to compare call stacks to detect a duplicate. AFAIK madExcept can do so automatically via a hash or something but we've never used that feature.

 

So the only advice I can offer is: fix your bugs before release 😉 

Think of errors retrieved from an external source mapped to Delphi exceptions in case of Oracle or SAP via Connect For SAP (formerly SAPx) for example. The abuse of exceptions to hint at errors in the business logic is no good idea at all. I can remember applications in the 1990s (Delphi flower power area) that were designed to hint at business logic errors via NIL pointer exception or better said EAccessViolations which show up calling virtual methods in Smalltalk 'Message Not Understood' style. I can live with retrieving error numbers raised and additional information gathered on the source system via Delphi exceptions and if people like they can include call stacks from the application. In a 24*7 server side environment an error raised at night and the applications has to continue working unattended (service, servers-side application, ...) errors mentioned are exceptional. Agreed. Even such exceptions have to be fixed as soon as possible and logged on both sides.

[Berocoder 24]

13 hours ago, Anders Melander said:

It sounds to me like you have a quality problem if you have that many exceptions.

 

In the applications that I work on (users in the hundreds), every single exception that are caught by the outer exception handler (madExcept in our case) is treated as a must-fix bug. On the average I would say we get one or two a month if we've been sloppy with the QA.

The madExcept bug reports are usually either mailed to us by the madExcept UI, or retrieved from the customer's system by our supporters, and attached to a JIRA issue. It is extremely rare that we need to compare call stacks to detect a duplicate. AFAIK madExcept can do so automatically via a hash or something but we've never used that feature.

 

So the only advice I can offer is: fix your bugs before release 😉 

Yes I agree that we have far too many exceptions. Most common ones is conflict between users. So 2 users try to update the same thing. One win and one loose.
And that in turn depends on the workflow. Many users see and edit the same data. We have OSS service (Object Synchronization Service) but it can take a second or 2 before all users are notified on a change.
But there is also other exceptions that actually should be fixed.
But this is a separate issue. It is just that it is not realistic to create a new post in issuetracker for all exceptions.

Now we read logs and create issues manually in issuetracker.

[Berocoder 24]

16 hours ago, Cristian Peța said:

EurekaLog can send data to a bug tracker. See https://www.eurekalog.com/help/eurekalog/index.php?bug_trackers_setup.php

We use MadExcept and data are sent to Mantis that uses MySQL (actually MariaDB). An SQL server can handle a huge amount of data.

 

Let EurekaLog send all exceptions to  a database is not an bad idea. The downside is that unlike a textfile it needs a tool to red it. Or a SQL prompt...

But we have already a system with log-files that contains various loggings, exceptions and callstacks.
This use one log-file per running process.

We are also working on a solution to log everything to one central place in Google Cloud Platform.
So that might be the final solution 😊

[Kas Ob. 121]

22 hours ago, Berocoder said:

Any advice for a good plan for this ?

I have few :

1) Get familiar with EurekaLog, being having the sources or not, with the source you will have faster and better understanding on how things is done, but in all cases spend few hours with its demos and the documentation, keeping in mind EL comes with default behavior but in no way you are obliged to follow it.

2) Use the real gem in EL, the customization, yes, you can customize every thing from error handling to generating the reports.

3) Don't go after a fast kill by replacing all the existing error handling with EL, in other words don't make a shock to your own source code while generating bugs unintentionally, keep the existing error handling for now and ship/build EL report with it, have a look here

https://www.eurekalog.com/help/eurekalog/how_to_add_information_to_bug_report.php

you can ship the existing logs and error report as fields or as attachments.

 

4) i don't like the EL components, not because they are bad, but by design these components are initialized after/while a form is created, this could be too late, use events and other EL API from its SDK, example for what important to browse and use

https://www.eurekalog.com/help/eurekalog/index.php?how_to_register_event_handler.php

https://www.eurekalog.com/help/eurekalog/index.php?index_eevents_routines.php

 

Lastly, don't let its new API design and functionality overwhelm you, take your time (and this is important) to test each API in a test project, before adding it to your production application, some functionality need understanding and tweaking.

 

ps:I had the chance to fix a project, it was big with its own error handling and reporting same as your case, i introduced EL gradually, combining both error reporting, and removing the existing (old) error handling, only few every few days, providing debug version of the application with EL capture all handled exception, then disable the ones that are solved using my own filter in code (using the events) sometimes the shear amount of handled or silent exception is in millions, due to stuff like integer overflow !, but in the end even those disappeared and the project become exception free, except the intended to be exception by design, and it wasn't worth change the application functionality to remove those.

 

Hope that helps.

[Brian Evans 109]

8 hours ago, Berocoder said:

Let EurekaLog send all exceptions to  a database is not an bad idea. The downside is that unlike a textfile it needs a tool to red it. Or a SQL prompt...

But we have already a system with log-files that contains various loggings, exceptions and callstacks.
This use one log-file per running process.

We are also working on a solution to log everything to one central place in Google Cloud Platform.
So that might be the final solution 😊

It can generate a text file per exception that contains much more than just the stack trace. You can then do whatever you want with the text file. The log viewer tool they provide can display the contents of that text file in an easy-to-read way - nicely formatted and split up. 

ref: https://www.eurekalog.com/help/eurekalog/bug_report_page.php

 

Edited December 11 by Brian Evans

[Lars Fosdal 1793]

For our apps, we use EL to capture the exception, then log them both to a local log file (debug out type) and to our database.

As mentioned, it is timewise expensive, so we take care to not use exceptions for normal flow control.