date:20140904

[jira] [Created] (KAFKA-1623) kafka is sometimes slow to accept connections

2014-09-04 Thread Shlomi Hazan (JIRA)

Shlomi Hazan created KAFKA-1623:
---

 Summary: kafka is sometimes slow to accept connections
 Key: KAFKA-1623
 URL: https://issues.apache.org/jira/browse/KAFKA-1623
 Project: Kafka
  Issue Type: Bug
  Components: core
Affects Versions: 0.8.1.1
Reporter: Shlomi Hazan


from SocketServer.scala:144
the Acceptor can wait up to 500 millis before processing the accumulated FDs. 
Also, the backlog of the acceptor socket seems not to be defined, which may be 
problematic if all 500 millis are elapsed before the thread awakes. setting the 
backlog is doable using the proper ServerSocket Ctor, and maybe better be 
provisioned via configuration.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSS] 0.8.2 release branch, unofficial release candidates(s), 0.8.1.2 release

2014-09-04 Thread Guozhang Wang

Just made a pass over the unresolved tickets tagged for 0.8.2, I think many
of them can be pushed to 0.8.3 / 0.9.

On Wed, Sep 3, 2014 at 8:05 PM, Jonathan Weeks jonathanbwe...@gmail.com
wrote:

+1 on a 0.8.1.2 release as described.

I manually applied patches to cobble together a working gradle build for
kafka for scala 2.11, but would really appreciate an official release —
i.e. 0.8.1.2, as we also have other dependent libraries we use as well
(e.g. akka-kafka) that would be much easier to migrate and support if the
build was public and official.

There were at least several others on the “users” list that expressed
interest in scala 2.11 support, who knows how many more “lurkers” are out
there.

Best Regards,

-Jonathan

Hey, I wanted to take a quick pulse to see if we are getting closer to a
branch for 0.8.2.

1) There still seems to be a lot of open issues

https://issues.apache.org/jira/browse/KAFKA/fixforversion/12326167/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel
and our 30 day summary is showing issues: 51 created and *34* resolved
and not
sure how much of that we could really just decide to push off to 0.8.3 or
0.9.0 vs working on 0.8.2 as stable for release. There is already so
much
goodness on trunk. I appreciate the double commit pain especially as
trunk
and branch drift (ugh).

2) Also, I wanted to float the idea of after making the 0.8.2 branch
that I
would do some unofficial release candidates for folks to test prior to
release and vote. What I was thinking was I would build, upload and
stage
like I was preparing artifacts for vote but let the community know to go
in
and have at it well prior to the vote release. We don't get a lot of
community votes during a release but issues after (which is natural
because
of how things are done). I have seen four Apache projects doing this
very
successfully not only have they had less iterations of RC votes
(sensitive
to that myself) but the community kicked back issues they saw by giving
them some pre release time to go through their own test and staging
environments as the release are coming about.

3) Checking again on should we have a 0.8.1.2 release if folks in the
community find important features (this might be best asked on the user
list maybe not sure) they don't want/can't wait for which wouldn't be too
much pain/dangerous to back port. Two things that spring to the top of my
head are 2.11 Scala support and fixing the source jars. Both of these
are
easy to patch personally I don't mind but want to gauge more from the
community on this too. I have heard gripes ad hoc from folks in direct
communication but no complains really in the public forum and wanted to
open the floor if folks had a need.

4) 0.9 work I feel is being held up some (or at least resourcing it from
my
perspective). We decided to hold up including SSL (even though we have a
path for it). Jay did a nice update recently to the Security wiki which I
think we should move forward with. I have some more to add/change/update
and want to start getting down to more details and getting specific
people
working on specific tasks but without knowing what we are doing when it
is
hard to manage.

5) I just updated https://issues.apache.org/jira/browse/KAFKA-1555 I
think
it is a really important feature update doesn't have to be in 0.8.2 but
we
need consensus (no pun intended). It fundamentally allows for data in min
two rack requirement which A LOT of data requires for successful save to
occur.

/***
Joe Stein
Founder, Principal Consultant
Big Data Open Source Security LLC
http://www.stealth.ly
Twitter: @allthingshadoop http://www.twitter.com/allthingshadoop
/

--
-- Guozhang

1 2 >

1 - 100 of 101 matches

Mail list logo