Close chan of Closer first before calling callback

[vjsamuel]

Calling the callback first before closing the channel is causing read from closed connection exceptions. Ideally the processing should stop first before calling Close() on the tcp connection.

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[elasticmachine]

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

[ph]

@vjsamuel Looking at the code of the TCP Input, I think you are right if we move the close of the channel. Now Looking at the TCP input code

beats/filebeat/inputsource/tcp/handler.go

Lines 99 to 104 in b089094

	if err != nil {
	// we are forcing a Close on the socket, lets ignore any error that could happen.
	select {
	case <-closer.Done():
	break
	default:

The select will also need to happen even if we don't get an error for this to works as expected.
Right now the callback is called which force a close on the TCP connection and make the Read() return an error and then the select is executed.

Now by closing the channel before the callback the following events will make the the handle stop:

• Either read return and errors and Done() is checked.
• Either the read hit the timeout deadl and Done() is checked
• Either I successfully read a message and Done() is checked.

[ph]

should have done the above comment with request changed.

[ph]

Lets remove the TODO here.

[ph]

Remove the comment and LGTM,

[ph]

This comment doesn't fit here, lets remove it.