EDI inbound R47011 - Create sales order/Purchase order (memory violation)

Rayxue

Well Known Member
Hi All
We use R47011 to generate sales order and related purchase order through EDI data, but UBE occasionally end with "E" and PDF last page show with either

"Business Function R470110 DataBaseUpdateSection at line 53 for event 13 in section Read/Edit EDI header has cause memory violation." or
"Business Function R470110 HaederDoSectionProcess at line 23 for event 13 in section Read/Edit EDI header has cause memory violation." Both refer to BF is B470011.

It looks not volume issue because sometime only 10 EDI invoices will cause above error. (most time we have more than 800).
it also not data issue because when job fail but if we use SAME EDI data run again, it can complete properly.


Thanks for any suggestions

E812
SQL server 2008
 
Last edited:

rsvconsulting

VIP Member
Memory Violation message in PDF or JDEDEBUG.log shall not reflect actual offending business function. Because Memory Violation message in PDF is to be written by UBE Kernel, which reads and process line by line based on event rule as a result it only indicates the first level business function (which is called by report). So if a certain UBE is calling any business function through UBE Kernel, which is waiting for called business function to return. If it fails, then Memory Violation Message is to be written in PDF. For this reason if you turn on UBE log, same message can be retrieved. For this case, it is very important for you to capture both UBE kernel log and CallObject Kernel log by setting tracing (which records callobject process) and UBE Logging Level 6.

As we have describe above, Memory Violation can be understood as violating memory safety which in turn returns unexpected result. So you need to resolve this message to guarantee the result you are getting is correct and valid.

Unlike interactive application, transaction volume in a certain batch may affect result so verify that whether there is any memory leak. If so, resolve memory leak first to move on to memory corruption. Most of time, memory leak and memory corruption can be related in batch.



Example 1:

R47011 (EDI Sales Order) Ends in Memory Error

A. PDF:
EventRule : Business Function R47011DetailDoSectionProcess at line 36 for Event 13 in Section Read/Edit EDI Detail has caused a memory violation.

B. How to debug:
1. Turn on logging for both UBE kernel and CallObject Kernel and focus on the business function ends abruptly and business function called by this termination.
2. Look for bug based on the business function object ID retrieved by above
3. (Optionally) review the business function code and make it sure codes for fix exist in it
 

HolderAndrew

Well Known Member
Hi,

over the years I have seen many memory related problems with UBEs, especially R47011, R42500 when used as subsystems. The trick for these is to stop the processes regularly after approx. 10000 orders. Other issues I have seen is when orders contain more than 1000 Lines (increment is 0.01) and of course if you have customizations using pointers then these must be freed. If you are using pristine code and can replicate the issue then you should be able to log a call with Oracle - otherwise you need to examine the custom code carefully and check where it bombs out. If it works sometimes and not others - then check for patterns. Is it user related? Happening at certain times of the day, etc. But if you get error msg refrring to single line of code that your mail suggests - then a good analyst should be able to find the problem

Best rgds

Andrew
 

Rayxue

Well Known Member
Hi,

Since UBE R47011 crash happened on /off for same EDI data, Can I free memory after each sales order created ? Does that means have to modify BF B470011 or change on UBE level ?

Thanks
 

BOster

Legendary Poster
I don't know how you would "free memory" after each sales order. Is this running as some sort of sub system job as someone else eluded too? You might be able to work around the issue by changing that configuration.

In other words, if it is some sort of resource leak you may be able to work around the issue by terminate the process more frequently. Having said that, a basic memory leak more than likely wont cause a memory violation - just a severe degradation in performance over time - that is until you run out of memory but you should be able to detect that situation. However, there are other resources in JDE that have a very static, finite amount of resources. The two that come to mind are jdeCache cursors (100 per jdeCache instance) and jdeStoreDataPtr/jdeRemoveDataPtr (1000 or 10,000?). If either of these types of resources are leaked you will quickly run out and you could get the memory violation error you are seeing. But if that was the case I would think that this WOULD be volume driven. In other words you should be able to re-produce this by running x number of orders through the process, or running 1 order through the process x number of times (if it is some type of subsystem thing where the process never terminates).

Bottom line though, if you are getting a memory violation message in a UBE it is most likely a bug in the code some place pure and simple and the only reliable way to resolve the issue is to fix the bug. Now, it could be a bug in the tools level code, I have come across those, but that would be extremely rare. My guess is that more than likely it is a bug in the business logic some place, i.e. one of the BSFNs. The only way you will probably be able to resolve this is by fixing the bug in the offending BSFN.

The only other thing I can think of of the top of my head is possibly something like Vertex. Are you running Vertex for tax/geocode? It's possible that there is a bug in your version of Vertex. JDE loads vertex modules and executes Vertex function calls in the JDE running process so if Vertex caused a seg fault of some kind I believe it would manifest itself with the error you are seeing in the UBE.

This is one of those things that unless you figure out how to re-produce it, it is very hard to troubleshoot. Best of luck to you - these kind of things can be very frustrating to track down.
 
Top