E9.0 Automatic dedicated kernel assignment to certain users

johnd

Well Known Member
Hi folks

We run 9.0 TR 9.1.5.3, upgrading to 9.2 soon (we run on AIX)

We have a problem bleeding users off JDE kernels if the connection is the MEP DSI user ID we use to connect using XML connector. It's a 'sticky' connection that stays open for subsequent ND3N BSFN calls etc
So I had an idea to give the MEP user it's own dedicated kernel to connect to.

Can this be setup at all?

Thanks

John
 
Last edited:

Tom_Davidson

VIP Member
You can set Call Object kernels to singleThreadedMode=Y, and assign one call object kernel per user, FOR ALL USERS. IMHO not a good option IMHO. But I'm not at all sure that would help as MEP DSI uses the XML kernel. when we run into issues we cycle the TCP/IP service for DSI.

Hope this helps some.

Tom
 

johnd

Well Known Member
Thanks Tom

I am just trying to find ways for our CNC to be able to hit that recycle kernel button without too many concerns for other E1 users

Out of interest, do you know what would happen to the kernel MEP DSI is using if CNc were to click that button?
I am hoping it sends a signal back to MEP DSI to go find another kernel for future calls???
 

TFZ

Well Known Member
I believe you'll get a whole bunch of timeouts on the DSI side that would require a restart. I *think* they fixed this in newer versions, maybe it was a mix of tools upgrades and DSI service packs that did it. Technically, this is why DSI always tries to push you to give DSI its own Enterprise Server.
 

johnd

Well Known Member
I believe you'll get a whole bunch of timeouts on the DSI side that would require a restart. I *think* they fixed this in newer versions, maybe it was a mix of tools upgrades and DSI service packs that did it. Technically, this is why DSI always tries to push you to give DSI its own Enterprise Server.

Thanks. We use MPE 9.0 SP12 HotFix 39 (not sure how old or new this is)

I'll try and test what happens in non PROD when we hit that button on kernels MEP/DSI uses to connect.
 

glen7x

Active Member
Thanks Tom

I am just trying to find ways for our CNC to be able to hit that recycle kernel button without too many concerns for other E1 users

Out of interest, do you know what would happen to the kernel MEP DSI is using if CNc were to click that button?
I am hoping it sends a signal back to MEP DSI to go find another kernel for future calls???
If you hit recycle kernel, no future connections will be made to that kernel. Existing connections are preserved until you log off.
So, once DSI makes a connection, hit recycle and you should not have any more connections to this kernel.
 

johnd

Well Known Member
If you hit recycle kernel, no future connections will be made to that kernel. Existing connections are preserved until you log off.
So, once DSI makes a connection, hit recycle and you should not have any more connections to this kernel.
Hi Glen

Thanks for this, forgive me if I'm misunderstanding something, but my understanding of how DSI connects to E1 is.... it connects then all future 'activity' MEP DSI wants to use going forward, use that FIRST kept open connection into E1. As it's supposed to be faster than asking for a new connection

So will that button it stop 'activity' or connections? As it's already connected in a way.

Or are you saying, if we ask all DSI users to log off in their own time, they will reconnect using a different kernel? Which is great if that's the case :)
 

TFZ

Well Known Member
Im a little rusty, but you may be safe with that version of MEP and that hotfix. It's been a few years since I was in a similar pickle. Mine was we used a BSSV service to tax calcs, and basically, if that went down, everything would zombie (really great stuff.) DSI would go with it, and people would get quite surly. It wouldn't go out to a new kernel, and you'd see xml object caller timeouts in both the DSI logs and the XML Dispatch kernels.

If I remember right, we were on 9.0 and had the hotfixes you applied, and that seemed to fix it. I sort of remember something being buried in the patch notes, and I couldn't get it from DSI, I had to find it myself. They just kept blaming our tools version (which, im their defense, was buggy.)
 
Last edited:

TFZ

Well Known Member
Holy spelling errors batman, how does one fix a post.... I had such bad flashbacks that I mangled the post...

Im a little rusty, but you may be safe with that version of MEP and that hotfix. It's been a few years since I was in a similar pickle. My experience was around a BSSV service for tax calcs that basically would zombie kernels out if the provider was down (really great stuff.) DSI would croak along with it, and people would get quite surly. DSI wouldn't go out to a new kernel, and you'd see xml object caller timeouts in both the DSI logs and the XML Dispatch kernels.

If I remember right, we were on 9.0 and had the hotfixes you applied, and that seemed to fix it. I sort of remember something being buried in the patch notes, and I couldn't get it from DSI, I had to find it myself. They just kept blaming our tools version (which, in their defense, was buggy.)
 

glen7x

Active Member
Hi Glen

Thanks for this, forgive me if I'm misunderstanding something, but my understanding of how DSI connects to E1 is.... it connects then all future 'activity' MEP DSI wants to use going forward, use that FIRST kept open connection into E1. As it's supposed to be faster than asking for a new connection

So will that button it stop 'activity' or connections? As it's already connected in a way.

Or are you saying, if we ask all DSI users to log off in their own time, they will reconnect using a different kernel? Which is great if that's the case :)
Hi John,
yes, if the users log off in their own time, they will reconnect to a new kernel and not the recycled kernel.
To reiterate - If you hit recycle, all current activity is maintained, future new connections is not enabled here.
However, if you have a forced recycle paramter, it will lead to the users being kicked out at the configured time. So if there is a forced recycle paramter set at 2 hours, it will kick users out after 2 hours after you recycle.
 

johnd

Well Known Member
Hi John,
yes, if the users log off in their own time, they will reconnect to a new kernel and not the recycled kernel.
To reiterate - If you hit recycle, all current activity is maintained, future new connections is not enabled here.
However, if you have a forced recycle paramter, it will lead to the users being kicked out at the configured time. So if there is a forced recycle paramter set at 2 hours, it will kick users out after 2 hours after you recycle.
Thank you Glen
 
Top