Yeah we’ve seen cases when the session timeout might also need increasing. Could you try upping it to something like 60000ms and let us know how it goes:
>> streamsProps.put(ConsumerConfig.SESSION_TIMEOUT_MS_CONFIG, 60000); Thanks Eno > On May 6, 2017, at 8:35 AM, Shimi Kiviti <shim...@gmail.com> wrote: > > Thanks Eno, > I already set the the recurve buffer size to 1MB > I will also try producer > > What about session timeout and heart beat timeout? Do you think it should > be increased? > > Thanks, > Shimi > > On Sat, 6 May 2017 at 0:21 Eno Thereska <eno.there...@gmail.com> wrote: > >> Hi Shimi, >> >> I’ve noticed with our benchmarks that on AWS environments with high >> network latency the network socket buffers often need adjusting. Any chance >> you could add the following to your streams configuration to change the >> default socket size bytes to a higher value (at least 1MB) and let us know? >> >> private static final int SOCKET_SIZE_BYTES = 1 * 1024 * 1024; // at least >> 1MB >> streamsProps.put(ConsumerConfig.RECEIVE_BUFFER_CONFIG, SOCKET_SIZE_BYTES); >> streamsProps.put(ProducerConfig.SEND_BUFFER_CONFIG, SOCKET_SIZE_BYTES); >> >> Thanks >> Eno >> >>> On May 4, 2017, at 3:45 PM, Shimi Kiviti <shim...@gmail.com> wrote: >>> >>> Thanks Eno, >>> >>> We still see problems on our side. >>> when we run kafka-streams 0.10.1.1 eventually the problem goes away but >>> with 0.10.2.1 it is not. >>> We see a lot of the rebalancing messages I wrote before >>> >>> on at least 1 kafka-stream nodes we see disconnection messages like the >>> following. These messages repeat all the time >>> >>> 2017-05-04 14:25:56,063 [StreamThread-1] INFO >>> o.a.k.c.c.i.AbstractCoordinator: Discovered coordinator >>> ip-10-0-91-10.ec2.internal:9092 (id: 2147483646 rack: null) for group sa. >>> 2017-05-04 14:25:56,063 [StreamThread-1] DEBUG o.a.k.c.NetworkClient: >>> Initiating connection to node 2147483646 at >> ip-10-0-91-10.ec2.internal:9092. >>> 2017-05-04 14:25:56,091 [StreamThread-1] INFO >>> o.a.k.c.c.i.AbstractCoordinator: (Re-)joining group sa >>> 2017-05-04 14:25:56,093 [StreamThread-1] DEBUG >>> o.a.k.s.p.i.StreamPartitionAssignor: stream-thread [StreamThread-1] found >>> [sa-events] topics possibly matching regex >>> 2017-05-04 14:25:56,096 [StreamThread-1] DEBUG o.a.k.s.p.TopologyBuilder: >>> stream-thread [StreamThread-1] updating builder with >>> SubscriptionUpdates{updatedTopicSubscriptions=[sa-events]} topic(s) with >> po >>> ssible matching regex subscription(s) >>> 2017-05-04 14:25:56,096 [StreamThread-1] DEBUG >>> o.a.k.c.c.i.AbstractCoordinator: Sending JoinGroup ((type: >>> JoinGroupRequest, groupId=sa, sessionTimeout=10000, >>> rebalanceTimeout=2147483647, memb >>> erId=, protocolType=consumer, >>> >> groupProtocols=org.apache.kafka.common.requests.JoinGroupRequest$ProtocolMetadata@2f894d9b >> )) >>> to coordinator ip-10-0-91-10.ec2.internal:9092 (id: 2147483646 rack: >> null) >>> 2017-05-04 14:25:56,097 [StreamThread-1] DEBUG o.a.k.c.n.Selector: >> Created >>> socket with SO_RCVBUF = 1048576, SO_SNDBUF = 131072, SO_TIMEOUT = 0 to >> node >>> 2147483646 >>> 2017-05-04 14:25:56,097 [StreamThread-1] DEBUG o.a.k.c.NetworkClient: >>> Completed connection to node 2147483646. Fetching API versions. >>> 2017-05-04 14:25:56,097 [StreamThread-1] DEBUG o.a.k.c.NetworkClient: >>> Initiating API versions fetch from node 2147483646. >>> 2017-05-04 14:25:56,104 [StreamThread-1] DEBUG o.a.k.c.NetworkClient: >>> Recorded API versions for node 2147483646: (Produce(0): 0 to 2 [usable: >> 2], >>> Fetch(1): 0 to 3 [usable: 3], Offsets(2): 0 to 1 [usable: 1], >>> Metadata(3): 0 to 2 [usable: 2], LeaderAndIsr(4): 0 [usable: 0], >>> StopReplica(5): 0 [usable: 0], UpdateMetadata(6): 0 to 2 [usable: 2], >>> ControlledShutdown(7): 1 [usable: 1], OffsetCommit(8): 0 to 2 [usable: >>> 2], OffsetFetch(9): 0 to 1 [usable: 1], GroupCoordinator(10): 0 [usable: >>> 0], JoinGroup(11): 0 to 1 [usable: 1], Heartbeat(12): 0 [usable: 0], >>> LeaveGroup(13): 0 [usable: 0], SyncGroup(14): 0 [usable: 0], Desc >>> ribeGroups(15): 0 [usable: 0], ListGroups(16): 0 [usable: 0], >>> SaslHandshake(17): 0 [usable: 0], ApiVersions(18): 0 [usable: 0], >>> CreateTopics(19): 0 [usable: 0], DeleteTopics(20): 0 [usable: 0]) >>> 2017-05-04 14:29:44,800 [kafka-producer-network-thread | >>> sa-5788b5a5-aadc-4276-916f-1640008c17da-StreamThread-1-producer] DEBUG >>> o.a.k.c.NetworkClient: Node -2 disconnected. >>> 2017-05-04 14:29:44,801 [kafka-producer-network-thread | >>> sa-5788b5a5-aadc-4276-916f-1640008c17da-StreamThread-1-producer] DEBUG >>> o.a.k.c.NetworkClient: Sending metadata request (type=MetadataR >>> equest, topics=) to node 1 >>> 2017-05-04 14:29:44,801 [kafka-producer-network-thread | >>> sa-5788b5a5-aadc-4276-916f-1640008c17da-StreamThread-1-producer] DEBUG >>> o.a.k.c.NetworkClient: Node -1 disconnected. >>> 2017-05-04 14:29:44,802 [kafka-producer-network-thread | >>> sa-5788b5a5-aadc-4276-916f-1640008c17da-StreamThread-1-producer] DEBUG >>> o.a.k.c.Metadata: Updated cluster metadata version 4 to Cluster >>> (id = JsVqjH3tS4CIcqpd2jkogA, nodes = [ip-10-0-91-10.ec2.internal:9092 >> (id: >>> 1 rack: null), ip-10-0-95-250.ec2.internal:9092 (id: 2 rack: null)], >>> partitions = []) >>> 2017-05-04 14:30:56,062 [StreamThread-1] DEBUG o.a.k.c.NetworkClient: >>> Sending metadata request (type=MetadataRequest, topics=<ALL>) to node 2 >>> 2017-05-04 14:30:56,073 [StreamThread-1] DEBUG o.a.k.c.Metadata: Updated >>> cluster metadata version 7 to Cluster(id = JsVqjH3tS4CIcqpd2jkogA, nodes >> = >>> [ip-10-0-95-250.ec2.internal:9092 (id: 2 rack: null), ip-10 >>> -0-91-10.ec2.internal:9092 (id: 1 rack: null)], partitions = >>> [Partition(topic = sa-events, partition = 0, leader = 1, replicas = >> [1,2], >>> isr = [2,1]), Partition(topic = sa-events, partition = 1, lea >>> der = 2, replicas = [1,2], isr = [2,1]), Partition(topic = sa-events, >>> partition = 2, leader = 1, replicas = [1,2], isr = [2,1])]) >>> 2017-05-04 14:31:06,085 [StreamThread-1] DEBUG o.a.k.c.NetworkClient: >>> Disconnecting from node 2147483646 due to request timeout. >>> 2017-05-04 14:31:06,086 [StreamThread-1] DEBUG >>> o.a.k.c.c.i.ConsumerNetworkClient: Cancelled JOIN_GROUP request >>> >> {api_key=11,api_version=1,correlation_id=16,client_id=sa-5788b5a5-aadc-4276-916f >>> -1640008c17da-StreamThread-1-consumer} with correlation id 16 due to node >>> 2147483646 being disconnected >>> 2017-05-04 14:31:06,086 [StreamThread-1] INFO >>> o.a.k.c.c.i.AbstractCoordinator: Marking the coordinator >>> ip-10-0-91-10.ec2.internal:9092 (id: 2147483646 rack: null) dead for >> group >>> sa >>> 2017-05-04 14:31:06,195 [StreamThread-1] DEBUG >>> o.a.k.c.c.i.AbstractCoordinator: Sending GroupCoordinator request for >> group >>> sa to broker ip-10-0-91-10.ec2.internal:9092 (id: 1 rack: null) >>> 2017-05-04 14:31:06,196 [StreamThread-1] DEBUG o.a.k.c.NetworkClient: >>> Sending metadata request (type=MetadataRequest, topics=<ALL>) to node 2 >>> 2017-05-04 14:31:06,200 [StreamThread-1] DEBUG >>> o.a.k.c.c.i.AbstractCoordinator: Received GroupCoordinator response >>> ClientResponse(receivedTimeMs=1493908266200, latencyMs=5, >>> disconnected=false, requestHeader= >>> >> {api_key=10,api_version=0,correlation_id=19,client_id=sa-5788b5a5-aadc-4276-916f-1640008c17da-StreamThread-1-consumer}, >>> responseBody={error_code=0,coordinator={node_id=1,host=ip-10-0-91-10.ec >>> 2.internal,port=9092}}) for group sa >>> >>> >>> On Mon, May 1, 2017 at 4:19 PM, Eno Thereska <eno.there...@gmail.com> >> wrote: >>> >>>> Hi Shimi, >>>> >>>> 0.10.2.1 contains a number of fixes that should make the out of box >>>> experience better, including resiliency under broker failures and better >>>> exception handling. If you ever get back to it, and if the problem >> happens >>>> again, please do send us the logs and we'll happily have a look. >>>> >>>> Thanks >>>> Eno >>>>> On 1 May 2017, at 12:05, Shimi Kiviti <shim...@gmail.com> wrote: >>>>> >>>>> Hi Eno, >>>>> I am afraid I played too much with the configuration to make this >>>>> productive investigation :( >>>>> >>>>> This is a QA environment which includes 2 kafka instances and 3 >> zookeeper >>>>> instances in AWS. There are only 3 partition for this topic. >>>>> Kafka broker and kafka-stream are version 0.10.1.1 >>>>> Our kafka-stream app run on docker using kubernetes. >>>>> I played around with with 1 to 3 kafka-stream processes, but I got the >>>>> same results. It is too easy to scale with kubernetes :) >>>>> Since there are only 3 partitions, I didn't start more then 3 >> instances. >>>>> >>>>> I was too quick to upgraded only the kafka-stream app to 0.10.2.1 with >>>> hope >>>>> that it will solve the problem, It didn't. >>>>> The log I sent before are from this version. >>>>> >>>>> I did notice "unknown" offset for the main topic with kafka-stream >>>> version >>>>> 0.10.2.1 >>>>> $ ./bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 >>>>> --describe --group sa >>>>> GROUP TOPIC PARTITION >>>>> CURRENT-OFFSET LOG-END-OFFSET LAG OWNER >>>>> sa sa-events 0 842199 >>>>> 842199 0 >>>>> sa-4557bf2d-ba79-42a6-aa05-5b4c9013c022-StreamThread-1-consumer_/ >>>> 10.0.10.9 >>>>> sa sa-events 1 1078428 >>>>> 1078428 0 >>>>> sa-4557bf2d-ba79-42a6-aa05-5b4c9013c022-StreamThread-1-consumer_/ >>>> 10.0.10.9 >>>>> sa sa-events 2 unknown >>>>> 26093910 unknown >>>>> sa-4557bf2d-ba79-42a6-aa05-5b4c9013c022-StreamThread-1-consumer_/ >>>> 10.0.10.9 >>>>> >>>>> After that I downgraded the kafka-stream app back to version 0.10.1.1 >>>>> After a LONG startup time (more than an hour) where the status of the >>>> group >>>>> was rebalancing, all the 3 processes started processing messages again. >>>>> >>>>> This all thing started after we hit a bug in our code (NPE) that >> crashed >>>>> the stream processing thread. >>>>> So now after 4 days, everything is back to normal. >>>>> This worries me since it can happen again >>>>> >>>>> >>>>> On Mon, May 1, 2017 at 11:45 AM, Eno Thereska <eno.there...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi Shimi, >>>>>> >>>>>> Could you provide more info on your setup? How many kafka streams >>>>>> processes do you have and from how many partitions are they consuming >>>> from. >>>>>> If you have more processes than partitions some of the processes will >> be >>>>>> idle and won’t do anything. >>>>>> >>>>>> Eno >>>>>>> On Apr 30, 2017, at 5:58 PM, Shimi Kiviti <shim...@gmail.com> wrote: >>>>>>> >>>>>>> Hi Everyone, >>>>>>> >>>>>>> I have a problem and I hope one of you can help me figuring it out. >>>>>>> One of our kafka-streams processes stopped processing messages >>>>>>> >>>>>>> When I turn on debug log I see lots of these messages: >>>>>>> >>>>>>> 2017-04-30 15:42:20,228 [StreamThread-1] DEBUG o.a.k.c.c.i.Fetcher: >>>>>> Sending >>>>>>> fetch for partitions [devlast-changelog-2] to broker ip-x-x-x-x >>>>>>> .ec2.internal:9092 (id: 1 rack: null) >>>>>>> 2017-04-30 15:42:20,696 [StreamThread-1] DEBUG o.a.k.c.c.i.Fetcher: >>>>>>> Ignoring fetched records for devlast-changelog-2 at offset 2962649 >>>> since >>>>>>> the current position is 2963379 >>>>>>> >>>>>>> After a LONG time, the only messages in the log are these: >>>>>>> >>>>>>> 2017-04-30 16:46:33,324 [kafka-coordinator-heartbeat-thread | sa] >>>> DEBUG >>>>>>> o.a.k.c.c.i.AbstractCoordinator: Sending Heartbeat request for group >>>> sa >>>>>> to >>>>>>> coordinator ip-x-x-x-x.ec2.internal:9092 (id: 2147483646 rack: null) >>>>>>> 2017-04-30 16:46:33,425 [kafka-coordinator-heartbeat-thread | sa] >>>> DEBUG >>>>>>> o.a.k.c.c.i.AbstractCoordinator: Received successful Heartbeat >>>> response >>>>>> for >>>>>>> group same >>>>>>> >>>>>>> Any idea? >>>>>>> >>>>>>> Thanks, >>>>>>> Shimi >>>>>> >>>>>> >>>> >>>> >> >>