BSSV associated COK zombie and BSFN uses cache

nkuebelbeck

nkuebelbeck

VIP Member
We use BSSV as a wrapper to execute JDE BSFNS. There are some of these function that use JDE Cache. In the instance that a COK goes zombie or is recycled, the clients executing BSSV's start getting 500 errors. This is because the association of that user to its COK is gone. The bssv can be instructed to auto-reconnect, meaning get a new COK. That only works when the BSFNs called by the BSSV DO NOT USE JDE CACHE(see DOC 1202613.1)

Currently the only way to get the user back up and running is to restart the BSSV service. (pain point)

I am wondering if anyone has found away around this?
 
If you've got a COK that crashes (zombies), there is no way to get anything back. The cache is destroyed. You need to find the reason it crashes and fix that.

Craig
 
To be clear, I'm not trying to get anything back from the cache. The COK BSSV is associated to could be used by other processes(say a web client). The web client could have crashed the COK and the BSSV starts returning 500 errors to clients. I'm just trying to find a way to NOT have to restart the BSSV service.

My understanding is that zombie kernels just happen. I think on average we see 3 a week. I've seen web clients throw them, BSSV(actually just the BSFNS getting called), etc. Never the same reason(can't reproduce so oracle can't fix), even when digging into logs.

Also,my understanding from the article, is that even if there were no zombies, kernel recycling would also cause the same problem.
 
If you have high usage of BSSV then its better to go for separate ES server for BSSV and RTEs that would minimize the occurrence and make it easy to bounce servers if need be with minimum/no impact on actual E1 Prod servers.
Not recommended solution but worth looking into.

Chan
 
If you have high usage of BSSV then its better to go for separate ES server for BSSV and RTEs that would minimize the occurrence and make it easy to bounce servers if need be with minimum/no impact on actual E1 Prod servers.
Not recommended solution but worth looking into.

Chan

What would you define as high usage? (i think we process 1-2 thousand daily)
 
It's not about usage, it's about service responsibility and isolation level. Let's your interop stack serve external users/services without internal (JDE Apps) interaction.
Of course it make sense if you have an interop process producing a relevant business value (may be even 10 transactions per day but with big business impact).

Regards.

Bruno Condemi
 
Back
Top