failed to open cursor due to reach the max #cursors

nkuebelbeck

nkuebelbeck

VIP Member
Has anyone see this before? I found this in the E1 JDE_somenumber.log.

CAC0001017 - (jdeCacheOpenCursor) failed to open cursor due to reach the max #cursors (5) for cache (81B3202080973)

It's happening when P3210 is called from sales order the 6th time for a configured item. The P3210 comes up blank.

Thanks
 
Make sure the function calling this jdeCacheOpenCursor is also calling the jdeCacheCloseCursor after the cursor is no longer needed.
 
Last edited:
This is a bug pure and simple. As Olavo stated jdeCacheCloseCursor is not being called. You are limited to a max of 100 open cursors on a given jdeCache instance (you should rarely ever need more than a couple open and no where near the max of 100). Unless there are mods to the objects in question I would guess that there should be a fix/esu that addresses this.

Edit:
I looked at your post again and it said a max of 5 from the log. I do remember seeing new api calls where you can specify the number of cursors you need, the idea being that you can specify less than the default of 100 to save resources or something. Could be that is what is happening... still a bug.
 
Brian is correct about the new API. It looks like that cache is using the newer cache init function which is specifying 5 cursors. He also points out that this is a bug and that is for sure. The question comes down to what is the bug? The way I see it, there are 2 possibilities here:


  1. The business logic is not closing those cursors when no longer needed ... this really needs to be fixed! Any opportunity to fix E1 memory leaks is a good one.
  2. It's possible that the business logic works in conjunction with that particular cache in such a way as to close those cursors at some point after all processing and didn't expect the possibility of more than 5 cursors ever being needed. If this is the case, you can change the call to jdeCacheInitEx to either supply a larger cursor value or a zero to use the default max. IMPORTANT: only go this route if you are positive the business logic does the cursor cleanup!!!
 
thanks for all the feedback. No modified objects involved. I've got an open case with oracle and they are sending me bugs to check after I sent them this error. Digging through configurator code might be in my future...
 
That is an important detail. I leads back to what Jeremy was saying. If you changed the code to open 100 cursors you would only be masking the problem not fixing the bug.
 
Is there a way I can correlate "cache (81B3202080973)" to a line of code/cache name?
 
You should be able to figure it out by turning on debugging on the call object kernel through Server Manager.
 
Problem is that logging or whatever is not going to log the API call that's NOT made. In other words the bug is that, jdeCacheCloseCursor is NOT being called at some point. This could be a bug in the called code or in the calling application. The only real way to figure out where the bug is will be to debug the C code.

I am not familiar with that module, but if all the jdeCache manipulation is in a single source file (B3202080????) I would look for jdeCacheCloseCursor and then, thru debugging look to see why it is not being called (of course, if you can't find that api call that might be the bug). It could also be a bug in the Sales Order module as well... not calling the other function correctly or failure to call a cleanup function of some sort.
 
i think my hope is to find where the cache is being created with 5 available cursors to get oracle looking there and make my point that cursors need to be closed or increase the cursor count if need be. Again, their call, not mine.

edit

Jan 11 11:04:26.108664 jdecache.c1642 - 272/6 WRK:BLANKED OUT_80000000_P3210 Entering jdeCacheOpenCursor (Called by: /OneWorld/Packages/DVF150605/source/CMFG/b3202080.c line 204)
Jan 11 11:04:26.108688 jdecache.c1721 - 272/6 WRK:BLANKED OUT_80000000_P3210 CAC0001017 - (jdeCacheOpenCursor) failed to open cursor due to reach the max #cursors (5) for cache (8B32020801)
 
Last edited:
Back
Top