Multi-server max client limits?

This topic has 12 replies, 7 voices, and was last updated 12 years, 9 months ago by Jim Rawls.

Creator

Topic
July 25, 2011 at 9:34 pm #52614
Jim Rawls
Participant
I haven
Creator

Topic

Viewing 11 reply threads

Author

Replies
- July 26, 2011 at 3:30 pm #74855
  mike brown
  Participant
  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
- July 27, 2011 at 4:47 pm #74856
  Jim Rawls
  Participant
  Thanks Mike.
  
  I don
- July 27, 2011 at 4:58 pm #74857
  Chris Williams
  Participant
  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.
- July 27, 2011 at 6:46 pm #74858
  John Mercogliano
  Participant
  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
- July 27, 2011 at 10:24 pm #74859
  Jim Rawls
  Participant
  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
- July 28, 2011 at 8:21 pm #74860
  Bob Moriarty
  Participant
  Jim,
  
  I’d be curious to see what tcpdump shows.
- July 28, 2011 at 11:59 pm #74861
  James Danley
  Participant
  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
- July 29, 2011 at 7:20 pm #74862
  Jim Rawls
  Participant
  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…
- August 8, 2011 at 9:08 pm #74863
  Jim Rawls
  Participant
  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.
- March 5, 2012 at 4:10 pm #74864
  Jim Rawls
  Participant
  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.
- March 5, 2012 at 6:09 pm #74865
  Jim Kosloskey
  Participant
  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.
- March 6, 2012 at 12:46 pm #74866
  Jim Rawls
  Participant
  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

Viewing 11 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.