mhus.de

 After installing nexus3 server in a kubernetes environment in the first view everything looks good. Server is running an accessible from the world. Users and roles are defined and working. But already in the first hours of working with the repository there are problems. The trick was retry the failed activity and everything went ok. It turned out that heavy activities failed a lot of times and a lot of retries have to be done to finish the tasks. Annoying if a release deploy failed. You need to increase the version number every time. There were a few support in the internet for the problems most of the time handling SSL problems between maven and nexus. But it did not fix the problem. It looks like maven and the used http library wagon have got problems with pooled connections if using ingress (a test with a standalone installation did not show the problem)  - The 'deep' reason is not really clear for me, need to invest more time for it. The solution is to deny wagon to use po

Overview Error reporting is most of the time underestimated because it is believed that it is clear how this works. But the real requirements are most of the time not clear and most of the time it is not working how it should. This article shows the needs and goals of good error reporting. It also shows how it is currently done and how it is related to logging. Specially in dedicated systems error reporting must be defined new. Reporting Why do we report errors? We want someone or something let to know that something went wrong.  This gives the first requirements for error reporting. We need to report whats wrong. Exact enough to understand the problem or to analyse it deeper.  To do this a static error message for the case is necessary and more dynamic data to describe the specific case. Also a stack trace should be delivered to show exactly the code line where the error occurs. The stack trace is not part of this contemplation because it depends on the underlying programming language