Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain 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/


+
Patrick Hunt 2011-12-28, 17:45
+
Camille Fournier 2011-12-28, 18:12
+
Camille Fournier 2011-12-28, 18:31
+
Camille Fournier 2011-12-28, 19:18
+
Patrick Hunt 2011-12-28, 19:24
+
Ted Yu 2011-12-28, 20:58
+
Patrick Hunt 2011-12-28, 21:04
+
Camille Fournier 2011-12-28, 21:10
+
Patrick Hunt 2011-12-28, 21:24
+
Camille Fournier 2011-12-28, 21:26
+
Patrick Hunt 2011-12-28, 21:32
+
Camille Fournier 2011-12-28, 21:53
+
Patrick Hunt 2011-12-28, 22:12
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
> >> >
+
Patrick Hunt 2011-12-28, 22:45