Rogue BPM Cache?

Does the blob contain executable image? Or is it source code that is then compiled (or interpreted?) on demand?

Epicor does this in the Epicor.Customization.dll on the Server

Assembly.Load(blob.Data, blob.Symbols);

It is my understanding that the Blob already contains a compiled Assembly, which is generated during Enable/Disable, that if you wrote it to disk you probably end-up with a valid .dll.

What is the BPM doing? Did you take a memory dump? @SAD any ideas on this one?

1 Like

A Blob is an actual file. It’s already compiled just loaded from the blob into memory. The “source” is stored as metadata and a thumbnail preview in Ice.BpDirective

I did not take a memory dump since it was kind of an emergency situation since everything was dragging and timing out.
All the BPM does is Post Processing Update in memorry TT records

This is all it did Post Processing on CashRecGetInvoices.


foreach(var x in ttARInvcAlloc)
  {
    
    var data = (from i in Db.InvcDtl where i.Company == x.Company && i.InvoiceNum == x.InvoiceNum group i by 1 into g
              select new { LineTotal = g.Sum(z=>z.DocExtPrice), MiscChargeSum = g.Sum(z=>z.DocTotalMiscChrg)}).FirstOrDefault();
              
    var tax =(from i in Db.InvcTax where i.Company == x.Company && i.InvoiceNum == x.InvoiceNum select i.DocTaxAmt).DefaultIfEmpty(0M).Sum();
    x["TotLineCharges_c"] = data.LineTotal;
    x["TotMiscCharges_c"] = data.MiscChargeSum;
    x["TotTaxes_c"] = tax;
    }

Did you review serverlog at the time when the directive slowed down the process?
Probably it had some exceptions that didn’t go to the client.

PS. Regarding transferring DB from pilot to production without regeneration of the ECF-based stuff…
It scares me :frowning:

No ideas. Looks like voodoo magic.
I have only one idea… For some reason BPM customization including this directive was not regenerated and runtime tried to use old version of it. But I have no idea how it can occur.

3 appserver load balancer so looking at logs is tricky but I did poke around nothing much of interest in any of the servers

Voodoo magic indeed

When this happened to @jgiese.wci a few years ago I told him he was a crazy idiot and that it couldn’t happen…. turns out :grimacing: sorry bud :disappointed: lol

Oh well I’ll keep an eye out if it happens a again I’ll do a memory dump and more things

Gremlins!

Thanks all

1 Like

giphy1

In general. it could be a reason. BPM uses a cross-host notification system provided by ICE FW.
AFAIR, by default, it utilizes DB and uses dedicated threads (on every host/pool) to detect new messages. So, under some conditions notification messages from the pool where a directive was enabled/changed/disabled can be delayed in processing (or probably even just missed). As a result, the host/pool that didn’t get a notification will use an old version of a compiled BPM customization.

It should be a rare case, but it is possible.

1 Like

Just adding I saw a similar situation with what appeared to be caching.

In testing, I wrote a bad a BPM that caused issue with normal operation that killed the client. I went to web config to disable all BPMs and was able to get back in and disable the offending BPM proper, then re-enabled BPMs globally.

I found the offending BPM was still hitting (even though it had been disabled!)

I killed all of the cache folders I am aware of.

Next I tried deleting the BPM. Same issue.

I even tried RECOMPILING all Directives.

I am not sure what ultimately fixed it, but I did use @hkeric.wci 's LinkedIn article to re-enable the exporting of sources, a few recycles and recompiles later it finally began to behave properly again.

?

1 Like

I am glad someone reads them. They are free too :smiley: Here is also a EpiUsers version so you can read it again.

2 Likes