Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # dev >> Re: svn commit: r1225200 - in /zookeeper/trunk: ./ src/java/main/org/apache/zookeeper/server/ src/java/test/org/apache/zookeeper/server/quorum/ src/java/test/org/apache/zookeeper/test/


Copy link to this message
-
Re: svn commit: r1225200 - in /zookeeper/trunk: ./ src/java/main/org/apache/zookeeper/server/ src/java/test/org/apache/zookeeper/server/quorum/ src/java/test/org/apache/zookeeper/test/
:)

That is a very good question. This should definitely be fixed in 3.5. I
think your general idea in that tracker comment is right on:

One option that would make this a lot less ugly would be to deprecate
> support for 4letterwords on the client port in 3.5.0 (dep, not remove,
> although provide an option to turn off via config), we'd designate a new
> port specifically for 4letterwords. We'd fix this problem on the new port,
> the old port would have the existing limitations.
>
> 3.6.0 we would remove 4lw on client port entirely.
>
> This is good for a number of reasons IMO – one is that having 4lw on the
> client port is a bit of a security issue in some customers - as any client
> has access to this port and it cannot by definition be firewalled. Many
> admins would like to firewall this.
>
> In the process we could:
> 1) make the new port fully b/w compatible with the existing functionality
> 2) enable long lived sessions rather than polling
> 3) provide support for "extended command syntax" which would enhance 4lw
> features (for example to control the format of the output)
> 4) etc...
>

Especially the points 1-4... we need this to be a handshake model, not just
a connect and dump model.
I want to work on this, but I will probably need someone a bit better at
python to rewrite your monitoring server to use it.
I would also welcome help on this issue, if there's someone else is
interested in tackling it, I am happy to provide feedback and guidance.

Should I start clean and make a new tracker or fold it into 1197?

C

On Wed, Dec 28, 2011 at 5:12 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:

> On Wed, Dec 28, 2011 at 1:53 PM, Camille Fournier <[EMAIL PROTECTED]>
> wrote:
> > Fair enough. Syncs for all! It's a drop in the bucket compared to the
> fact
> > that we aren't handling the fundamental socket connections for 4lws
> > correctly anyway.
>
> sorry. I see a blog post coming on. ;-)
>
> You're referring to the following (any more?)
> https://issues.apache.org/jira/browse/ZOOKEEPER-1197
> https://issues.apache.org/jira/browse/ZOOKEEPER-1237
>
> is this comment still a correct interpretation of the issue?
>
> https://issues.apache.org/jira/browse/ZOOKEEPER-737?focusedCommentId=13109067&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13109067
>
> What would you like to do about these? I had proposed having a
> separate 4lw port some time back in order to simplify/isolate. Should
> we do this for 3.5.0? (deprecate the old port usage but keep it around
> for a while) Something else?
>
> Patrick
>
> > On Wed, Dec 28, 2011 at 4:32 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> >
> >> On Wed, Dec 28, 2011 at 1:26 PM, Camille Fournier <[EMAIL PROTECTED]>
> >> wrote:
> >> > I'm not sure I agree in the assumption that monitoring pulls happen
> >> > infrequently...
> >>
> >> Well that would be bad news then - see "stat" command processing and
> >> similar. All the more reason to look at this in more depth.
> >>
> >> Patrick
> >>
> >>
> >> > On Dec 28, 2011 4:24 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
> >> >
> >> >> They seem like distinct changes to me. In particular getting the size
> >> >> is going to happen infrequently (monitoring pull) so I don't see a
> >> >> problem fixing the existing patch in the same way the code currently
> >> >> handles cnxns access, with a separate jira to do the refactoring. Am
> I
> >> >> missing something?
> >> >>
> >> >> Patrick
> >> >>
> >> >> On Wed, Dec 28, 2011 at 1:10 PM, Camille Fournier <
> [EMAIL PROTECTED]>
> >> >> wrote:
> >> >> > I don't think creating it as a flat sync is a good idea, so if we
> want
> >> >> this
> >> >> > I think we need to refactor that structure to be concurrent.
> >> >> >
> >> >> > C
> >> >> > On Dec 28, 2011 2:24 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
> >> >> >
> >> >> >> I think it needs to be fixed. It's obviously incorrect. Also if
> >> >> >> someone changes the underlying implementation at some point it
> might
> >> >
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB