zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Flavio Junqueira <fpjunque...@yahoo.com.INVALID>
Subject Re: <Unverified Sender>RE: exposing lastSend
Date Wed, 16 Jul 2014 20:49:44 GMT
Hi Austin,

I feel your pain, but what's it concretely that you'd like to happen? That we expose last
send or that we also make the JNI wrapper around the C client happen or both?


On Wednesday, July 16, 2014 7:36 PM, "Miller, Austin" <Austin.Miller@morganstanley.com>

>I'm still hoping to spark some discussion about the last send value.
>Given the links below...
>It seems the issue of thread starvation has been considered previously and is considered
sufficiently important to possibly pursue a JNI solution.
>While a JNI wrapper around a C client might increase the likelihood of ZooKeeper client
threads being scheduled in the OS, it does not completely ameliorate the issue.  Resource
starvation, memory, threads, and IO, may still prevent the client from being scheduled even
in a C program.
>It also adds new sources of failure, more complexity, and increases difficulty of deploying
>There still seems to be a race condition, in the JNI solution, between session loss notification
and Java if a partition and pause happen simultaneously.
>If it is assumed that long pauses happen for some users and the last send value is exposed,
then I maintain it is possible to use that value in ways that increase the chances that a
transaction is not committed when a session has been lost.  Some users may actually want
failover in the case of a really long pause in the JVM, as well.  From the cluster's point
of view, the app rebooted.
>GC pauses are not the only things that cause resource starvation, either, and a cause
agnostic measure, like using the last send value to gate writes, is going to provide more
confidence than a JNI wrapper around C.
>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 messaging with Morgan Stanley
you consent to the foregoing.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message