In this blog post, I will walk you through the process up starting support cases at Red Hat. Including examples of what we did to solve our case. However, these blog posts might still help you when starting support cases at other companies.
One of the cases we have started is a case regarding a bug in JBoss EAP 7.1.4 where JMS connections were not properly closed when consuming and producing a message to a JMS Queue within one transaction. Obviously, we did not know the cause at the start of the case.
It is not your job to solve the case for them, you should only make it as easy as possible for them to help you with your issue. So that is what we have tried to do, and I will try to help you with using this blog.
When to start a case
When we found the following log entry:
[org.jboss.jca.core.api.connectionmanager.ccm.CachedConnectionManager] (Thread-17 (ActiveMQ-client-global-threads)) IJ000100: Closing a connection for you. Please close them yourself: org.apache.activemq.artemis.ra.ActiveMQRASession@77424f5f: java.lang.Throwable: STACKTRACE
We first started searching using Google and Red Hat’s solution-engine, however after not finding anything we decided to open a case at Red Hat.
There are several occasions when you could start a case at Red Hat. We have opened several cases for bugs we found or when we had configurational issues/questions. However, having a configurational issue or bug does not mean you should instantly open a new case. This is probably obvious but you should google first and search on Red Hat’s solution-engine if there is not an already existing case which answers your questions.
Preparing a case
After deciding to open a support case, we started gathering all information which would be valuable for Red Hat to reproduce the issue and help us solve our problem.
So, you have checked the internet on a similar existing case, did not find anything and decided to open a support case. Great! Now we have a valid subject to start a new case at Red Hat! Now you should start preparing to open the case. This includes the following:
Articulate your issue short but clear. So you should make clear what your issue is, what you expect to happen and what is actually happening. If you are describing the issue clearly enough, you will save lots of time answering questions and waiting for a response when you could have prevented this by describing your issue well. Make sure you also mention the occurrence of the issue.
In our case, we mentioned exactly what happened before, during and after the occurrence of the log entry. In addition to this, we could also mention when it occurred, in our case the issue occurred when we multiple components used the broker simultaneously. This combined with our test case mentioned below made it easy for Red Hat to acknowledge the bug.
Gather your logging, configuration and optionally your source code to reproduce the issue. Make sure that the source code is as small as possible but does reflect your actual code. You should also prepare a roadmap to reproduce your issue step by step.
At first, we always research our problem ourselves by trying to reproduce the issue in an as small as possible environment so that we can send this to Red Hat. In addition to this, we also gather logging of our components using the queue as well as the queue’s logging itself.
Define the urgency of your case
Red Hat likes you to provide the urgency of your case, use the guide to help you with determining what level of urgency your case is. A general configuration issue has a lower urgency classification than i.e. a production issue including data loss. Since we had an issue on our productional environment, and we could not determine the consequences of our issue except for that we did not lose any data. We stated our urgency on level 2 High.
If you do set the urgency wrong according to Red Hat they will be discussing this why it should be a higher/lower urgency level.
Starting the case
Next, If you are done preparing, you should open a new case! Log in at Red Hat and start a new case, for more specific details to open a case see Red Hat’s article. Fill in all required fields and start your case description using your prepared issue description, the roadmap to reproduce and attach the logging, configuration and source code to the case.
Remember to provide everything you’ve prepared before. The better you prepare, the better Red Hat will be able to help you fix your issue as fast as possible.
Some extra tips that might be helpful during your case:
Always be polite
Think about it, if someone is not respecting you. Will you help them to the fullest extent?
Never handle a case alone
Two people know more than one, so always handle a case with one of your colleagues. Even if they know nothing about the issue. Also sparring with a colleague might be helpful when Red Hat asks you questions.
Know when to escalate
At Red Hat there is a possibility to escalate a case, so use it when needed. Like we did when we had a case with possible data loss in production going on and at Red Hat, someone took over the case. We had the feeling we started all over again and all our work and communication over the weekend had been thrown in the bin.
Keep your case clean
Ask for one issue, having multiple issues at the same time that can be separated, separate them by opening multiple cases! When not separating issues properly, Red Hat might not be able to handle your issues well because of the mixed up issues within one case. Separating these brings focus, to Red Hat but also yourself. An additional advantage is the priority management. You will be able to set a higher/lower priority on each issue.