Multi-server max client limits?

[Jim Rawls]

I haven

Topic

[mike brown]

Hi Jim

You might want to review and look into the The default keepalive script, it is in half seconds, you can increase or decrease.. This is reset after re-boot of server.

also see Paul’s post about nine below yours in forum

we used the settings to keepalive faster down to 900

To determine current keepalive setting:

$ no -a | grep tcp_keepidle

[Jim Rawls]

Thanks Mike.

I don

[Chris Williams]

Just to clarify a minor point, the half-second units apply only to AIX (IBM), for all other Unix-like operating systems, the units are full seconds.

[John Mercogliano]

Jim,

 Just to clarify, it sounds like you turned on driver control to look at the ports.  That should always be on for multi server.  

In any case, it almost sounds like they are not receiving the reply because it is going out on the wrong port.  Have you verified that that the reply procedure you are using is adding the original messages driverctl metadata to the reply message?

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Jim Rawls]

John,

Yes, we do have driver control on, and it is passing back in the DRIVERCTL metadata on the ACK.  I could see this with the engine

[Bob Moriarty]

Jim,

I’d be curious to see what tcpdump shows.

[James Danley]

Jim,

When using Multi-Server you need to get the CONNID from the DRIVERCTL in the inbound message. An then place it into the reply message. If you don’t Cloverleaf will not know which connection to send the reply to.

Example:

msgmetaset $mhReply DRIVERCTL [msgmetaget $mh DRIVERCTL]

James Danley | Learning Consultant, Principal
James.Danley@infor.com | http://www.infor.com

[Jim Rawls]

Thanks James.  We do have that setup correct.

In the short term, we are working around the problem by throttling the sending system.  After our Linux admins finish with the disaster recovery exercise  next week, we’re going to schedule a tcpdump session.  Hopefully that will help get to the bottom of this…

[Jim Rawls]

We were able to run tcpdump between the 2 nodes last week.  Our network admin gave us a clean bill of health.  Turns out they sit on the same switch, which also showed no errors.  

In a very few cases, the messages were actually lost and never showed up on the Cloverleaf logs.  In the mean time we have been able to work around the problem by throttling the other system to the point that we no longer receive errors or lose messages.

This brings me back to my original question regarding limits for multi-server connections… are there any?  I guess my next step will be to talk to support.

[Jim Rawls]

I wanted to post a follow-up in case anyone runs into this in the future.  We ultimately resolved this by putting Cerner inbound to HTTP outbound into a process by themselves, and the multi-server thread and thread back to Cerner in another process by themselves.  Thanks to Lawson for their diligence and patience in helping us figure this out.

[Jim Kosloskey]

Jiim,

Did you use cross process message delviery or did you set up localhost threads to send from one process to another?

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Jim Rawls]

Hi Jim,

Neither, as we didn’t have to cross processes.  The X12 270 transaction from the Cerner thread was sent to the outbound HTTP thread; those 2 threads only were in the first process.  The X12 271 transaction inbound to Cloverleaf – the multi-server thread – was in the second process with the outbound Cerner thread (pdl tcpip config).  This seemed to give the inbound multi-server connection dedicated resources; in our original configuration, all four threads were in the same process, and when batch 270s went out and all of the 271 responses flooded back in, the process was overwhelmed.

[Author]

Replies