Ah, make sense. It seems that this is already fixed in 0.8.2 and trunk.
Thanks,
Jun
On Fri, Dec 12, 2014 at 5:34 PM, Helin Xiang wrote:
> Hi, Jun
>
> What you said is right, but in the code of simpleconsumer ( where the
> BlockingChannel.disconnect()
> will be called ), it firstly checked if t
Hi, Jun
What you said is right, but in the code of simpleconsumer ( where the
BlockingChannel.disconnect()
will be called ), it firstly checked if the channel is connected, that's
the real problem.
And we reproduced the problem in our testing environment.
first we use iptables to drop packet and
Hmm, but if we hit an exception in BlockingChannel.connect(), we will
call BlockingChannel.disconnect(), which will close the socket channel.
Thanks,
Jun
On Tue, Dec 9, 2014 at 7:09 PM, Helin Xiang wrote:
> Hi, Jun
>
> We experienced a network device problem. and cause all brokers crashed.
> A
Sorry for me not replying in the thread. ignore last email.
Hi, Jun
We experienced a network device problem. and cause all brokers crashed.
After investigation, we found server log throw similar exceptions.
this:
java.nio.channels.UnresolvedAddressException
at sun.nio.ch.Net.checkAddre
Hi, Jun
We experienced a network device problem. and cause all brokers crashed.
After investigation, we found server log throw similar exceptions.
this:
java.nio.channels.UnresolvedAddressException
at sun.nio.ch.Net.checkAddress(Net.java:29)
at sun.nio.ch.SocketChannelImpl.connec
This is fixed in https://issues.apache.org/jira/browse/KAFKA-1228 and will
be included in 0.8.1 release.
Thanks,
Jun
On Wed, Feb 12, 2014 at 6:28 PM, Priya Matpadi
wrote:
> Hello,
> Is there any progress on this issue? We also experience socket leak in case
> of network outage.
> Thanks,
> Pri
Further more, the problem is not just restricted to ReplicaFetcherThread.
Kafka consumer server also leaks sockets due to SendThread using same code
. See below stack trace:
2014-01-23 06:48:09,699 INFO [org.apache.zookeeper.ClientCnxn]
(OurKafkaMessageFetcher-blah1-SendThread(pkafka3.our.com:218
Hello,
Is there any progress on this issue? We also experience socket leak in case
of network outage.
Thanks,
Priya
On Fri, Jan 24, 2014 at 7:30 AM, Jun Rao wrote:
> Thanks for find this out. We probably should disconnect on any exception.
> Could you file a jira and perhaps attach a patch?
>
>
Thanks for find this out. We probably should disconnect on any exception.
Could you file a jira and perhaps attach a patch?
Thanks,
Jun
On Fri, Jan 24, 2014 at 6:06 AM, Ahmy Yulrizka wrote:
> Hi,
>
> I Think I found out the problem..
>
> this is part of the stack trace. First i think there is
Hi,
I Think I found out the problem..
this is part of the stack trace. First i think there is connection problem,
and when connection restore it get new information from the zookeeper
[2014-01-23 23:24:55,391] INFO Opening socket connection to server
host2.provider.com/2.2.2.2:2181 (org.apache.z
Hmm, without knowing the client ip, it's hard to tell whether those are
from replication fetcher threads or not. Are most of those connections in
established mode?
Thanks,
Jun
On Tue, Jan 21, 2014 at 8:06 AM, Ahmy Yulrizka wrote:
> this is the the line i copied on lsof
>
> ...
> java 118
this is the the line i copied on lsof
...
java 11818 kafka 98u sock0,7 0t0
615628183 can't identify protocol
java 11818 kafka 99u IPv4 615077352 0t0
TCP somedomain.com:9092->121-123-123-123.someprovider.net:37547(CLOSE_WAIT)
What mode are those sockets in (established, closed, etc)? Also, from the
ip, could you tell whether those sockets are from the client or from the
replica fetcher in the brokers.
Thanks,
Jun
On Tue, Jan 21, 2014 at 3:29 AM, Ahmy Yulrizka wrote:
> We are running 3 kafka nodes, which servers 4
13 matches
Mail list logo
