Hello Zoltan, We likely need to retain the logic that forces a connection close. Since the length advertised by the client feeds into a buffer allocation on the server, we protect against large values that would bloat the server's memory footprint. A client advertising a huge length might not be trustworthy, so we close it. It doesn't look feasible to set up any more meaningful response, such as an error code, because the server has intentionally chosen to violate protocol by ignoring the remaining request bytes sent by the client.
When this happens, you would see a "Len error" message in the server logs. If you have any thoughts on making this condition more visible to operators, please feel free to file a ZooKeeper issue in Apache JIRA with your request. That's something we could consider. Chris Nauroth On Wed, Nov 30, 2016 at 4:33 AM, Szekeres, Zoltan < [email protected]> wrote: > Hi ZooKeeper team, > > We've run into the situation where we've sent more than 1MB of data with a > create request and the server closed the connection. I understand this is > an abuse of the system and it's not recommended and also it can be > configured via "jute.maxbuffer". However it's not obvious at first look > what has caused the connection to be closed, because only a connection loss > is seen by the client. Also if we retry on connection loss (which is done > automatically by Apache Curator), we retry the operation until our retry > policy allows it, which means creating a new connection on each retry. > Would it be possible to change the behavior to return an error code, > instead of closing the connection? > > Thanks, > Zoltan Szekeres > > > > ________________________________ > > NOTICE: Morgan Stanley is not acting as a municipal advisor and the > opinions or views contained herein are not intended to be, and do not > constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall > Street Reform and Consumer Protection Act. If you have received this > communication in error, please destroy all electronic and paper copies and > notify the sender immediately. Mistransmission is not intended to waive > confidentiality or privilege. Morgan Stanley reserves the right, to the > extent permitted under applicable law, to monitor electronic > communications. This message is subject to terms available at the following > link: http://www.morganstanley.com/disclaimers If you cannot access > these links, please notify us by reply message and we will send the > contents to you. By communicating with Morgan Stanley you consent to the > foregoing and to the voice recording of conversations with personnel of > Morgan Stanley. >
