| Author |
Message
|
| learner.ibm |
 Posted: Wed Dec 07, 2016 3:21 am Post subject: IIB bar file getting corrupted |
 |
|
Novice
Joined: 10 Nov 2016
Posts: 10
|
We are getting issues with the bar file getting corrupted most often in production environment and due to this message flows stops working.
Once we redeploy the corrupted bar file the flow works fine.
Any idea how to overcome this issue?
Appreciate your suggestions and responses.
Thanks in advance |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Dec 07, 2016 4:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Once you deploy a bar file, it doesn't exist any more.
Once you deploy a bar file, then the code in it shouldn't get 'corrupted'.
The message flow might "break", but how it does that, and what causes it are things that only you can determine. If by 'corrupted' you mean "stops processing messages", then the first thing to look at is your code to see if it is an infinite loop.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| learner.ibm |
| Posted: Wed Dec 07, 2016 5:13 am Post subject: |
|
|
Novice
Joined: 10 Nov 2016
Posts: 10
|
Thanks Jeff.
Yes all message flows stops processing. I did check the code and we don't have infinite loop. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Dec 07, 2016 5:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| learner.ibm wrote: |
Thanks Jeff.
Yes all message flows stops processing. I did check the code and we don't have infinite loop. |
All flows that were in the BAR?
Or all flows in the EG?
Look at the broker error log.
Run a user trace.
Just because you examined the code, that doesn't mean you aren't running into an infinite loop when the code is running.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| learner.ibm |
| Posted: Wed Dec 07, 2016 10:31 pm Post subject: |
|
|
Novice
Joined: 10 Nov 2016
Posts: 10
|
Actually Jeff, the issue is reported by our support team and when I wanted to understand more about IIB bar file getting corrupted. They say the issue is sometimes, header part is missing when we access the WSDL. In this case call from BPM to IIB fails. With this assumption they have considered as the IIB bar file getting corrupted and in this scenario they always redeploying the bar file when they face this issue and this seems to be occurring more often in production environment.
In the above case the header part or body part which seems to be missing is not specific to a particular module or flow for which they can enable and run trace logs.
Can you please suggest in which scenario this kind of issue is arrived and what could be the solution?
Thanks for understanding and your support. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 08, 2016 5:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So, let's review what I understand, to make sure I'm not wrong. - After some period of time, the flow stops processing data correctly
- The flow stops responding correctly because the WSDL is not correct
- The WSDL is not correct because a header is not being returned when BPM accesses the WSDL
- They resolve this problem by redeploying the bar file
If all of these things are correct, then the problem is *not* with the BAR file. The bar file is only used by the runtime when it is deployed. After that, the bar file *does not exist* in the runtime.
So it is not the case that "the bar file gets corrupted". So that thought has to be discarded entirely.
There are two, at least to my mind, meanings of "when we access the WSDL". The first is during the development of the BPM program. The second is during runtime, by the BPM program, so it can validate or otherwise make use of the WSDL to build the data it is sending to IIB.
In neither case, to the best of my knowledge, would a "header" not be returned. The whole WSDL would be returned, or an error would be returned trying to get the WSDL.
The only header I can think you mean is the SOAP header part of the response message to a SOAP request.
That brings us back to the message flow logic. This then requires the support team to run a user trace when the error occurs, so that you can analyze the results and find out what is being returned, and where the issue in your code occurs.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 08, 2016 5:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Allow me to underscore the excellent advice of my most worthy associate with this:
The bar file is a package containing the flows and other artifacts to be deployed.
The bar file itself is not deployed, what it contains is.
If redeploying the bar file fixes the problem, that's because redeploying the flow fixes the logic problem with it, probably by resetting some flag or memory area.
Focus, as my most worthy associate says, on diagnosing the flow with a user trace.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| learner.ibm |
| Posted: Thu Dec 08, 2016 10:03 am Post subject: |
|
|
Novice
Joined: 10 Nov 2016
Posts: 10
|
Thanks Jeff and Vitor for your responses.
I'll ask my support team to enable trace logs to find out the root cause.
When I actually asked them to enable trace logs they denied stating we have many flows and can't predict in which flow the problem arises.
According to them enabling trace logs in all the flows will have performance issues.
Still I'll ask them to enable trace logs for the particular module which they encountered issue for not having SOAP header for the accessed IIB msgflow.
I'll keep posted on the updates.
Thanks a lot for your guidance and support. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 08, 2016 10:05 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Make sure that you tell them "user trace", rather than "service trace".
User trace is a lot less impact, and produces smaller files.
Also ask them for a copy of the log file where broker outputs it's log entries - this is likely /var/log/messages, unless they've changed things.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
|
|
