Why do server reboots tend to fix all?

[Former Member]

I had an interesting resolution to a curious problem today. The issue centred around the development of a BPM, that when testing was completed in the development environment the receiver destinations were extended to include the QA (or Test) environments.

At this point the associated queue returned the dreaded "Permanent error in BPE inbound processing" error. After ensuring all the configuration was accurate, correct and identical to that of the development destinations (of course not the specific business system) and a couple of cache refreshes to boot, I was no closer to understanding either the cause nor solution.

I requested a server reboot - which has miraculously resolved the problem and messages are flowing as expected.

So my question is, what additionally happens when a server reboot to PI that doesn't happen with say a complete cache refresh?

Are there any other methods to along with a cache refresh that can help resolve problems such as "Permanent error in BPE inbound processing" when your sure no configuration or data is an issue?

[prateek]

One thing regarding BPM could be open instances, which may get terminated during reboot. These open instances could cause BPM related errors.

Regards,

Prateek

[Former Member]

Thats interesting, because I would have thought that restarting the BPE directly would have resolved any instance problems?

Come to think of it, I didn't restart java - could a restart of the Java stack be significant??

Edited by: Jason Coates on Aug 5, 2010 11:22 AM

[prateek]

BPE is ABAP engine based. Therefore I don't think that the restart of Java alone would have helped.

Regards,

Prateek

[Former Member]

Yes, which is why I didn't restart it. However, it was a service that would have been restarted with the server. Therefore, perhaps a dependent configuration element was "refreshed" along with the reboot.

Really am clutching at straws trying to understand what I could have restarted without having to reboot the server.

Particularly given the work process log provided no explanations as to the cause.

[former_member200962]

This is a mystery....it happens that even the CACHE refresh does not resolve the issue and in such cases a server restart is performed....though not a good practice...but unavoidable.

It necessarily need not be a service that got restarted, can even be the CACHE that got refreshed.

Regards,

Abhishek.

[Former Member]

So is that the prescribed course of action - that if a complete cache refresh doesn't resolve the issue, and your adament that nothing else could be wrong, you reboot the PI server?

[former_member200962]

yes....if nothing works out then server restart is the (last) option so that the CACHE is refreshed completely.

[prateek]

If you face this error again, goto transaction SWWL and delete all open BPM instances before going for reboot. Although this is not recommended to be used in production unless you are sure about which message could get lost.

Regards,

Prateek

[Former Member]

I had already checked SWWL and didn't find anything to worry about, or related to the BPM I was developing.

The problem, I think had something to do with the Integrated Process being directed to a new business system - as to why, I have no idea, I've never had this issue with more straight forward messages non-bpm messages, where once completed in the Dev system, I just add a new receiver with a simple condition to either force a non use or if the message contains system data that can determine with business system to direct itself too, as in dev vs. test.

Within SXI_CACHE when I perform a complete cache refresh - surely, that means COMPLETE. And a server reboot couldn't do anything more.