Skip to content

Conversation

@ljiang1
Copy link
Contributor

@ljiang1 ljiang1 commented Jul 23, 2017

check if the action is execute before execute the generate command

import re

pattern = re.compile(r'chunked 1.0,(?P<metadata_length>\d+),(?P<body_length>\d+)\n')
pattern = re.compile(r'chunked 1.0,(?P<metadata_length>\d+),(?P<body_length>\d+)')
Copy link
Contributor

@shakeelmohamed shakeelmohamed Jul 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we make the newline optional at the end with \n??


match = pattern.match(line)
if match is None:
continue
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we have this logic, the following assertIsNotNone is not needed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

resolved.

@itay
Copy link
Contributor

itay commented Jul 24, 2017

@ljiang1 I'm still kind of confused how this fixes the issue?

@ljiang1
Copy link
Contributor Author

ljiang1 commented Jul 25, 2017

@itay As Jacob suggested in previous pr, comparing to streamingcommand and other commands, before they call the customer supplied execution, they executed the searchcommands._records_protocol_v2(), which read the reply from splunk and check if the reply action is execute; but the generatingcommand didn't call _records_protocol_v2(). the fix is adding the same checking code as _records_protocol_v2(). The reason can't do the same calling format as streamingcommand is that the way of _records_protocol_v2() implements prevents the yielding result, so I end up just add the check code here.

@ljiang1
Copy link
Contributor Author

ljiang1 commented Jul 25, 2017

@leverich @itay by doing the read_chunk of splunk reply, somehow it terminates the getinfo only processes that added by optimizer code... maybe it is defined by the protocol? @leverich

@leverich
Copy link

If the script is being invoked just for getinfo, splunkd will close the processes' stdin after it receives the getinfo reply, so the SDK should read an EOF. Since this change adds the _read_chunk to _execute, it will detect the EOF and return None and return early from _execute. Thus, the GeneratingCommand's generate() method is never called in the case that this is just an invocation for getinfo.

I believe this change should address the immediate bug we're seeing (generate() method being invoked multiple times when it shouldn't be).

I think there's a separate issue with the GeneratingCommand class in that it only ever emits one chunk (e.g. you couldn't have a generating command that generates an infinite stream of events). That's a pre-existing problem and doesn't need to be addressed as part of this bugfix.


if len(chunks) == 0:
self.assertEqual(ifile.readline(), '\n') # the getinfo exchange protocol requires this
# if len(chunks) == 0:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How come this is commented out? I'd prefer to not see new commented-out code committed to the repo.

Copy link

@leverich leverich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, except for the commented out code. Figure out if that needs to stay or go and then I'm happy.

body=""
try:
body = ifile.read(body_length)
if body_length>0:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: spaces

# if body_length <= 0:
# return metadata, ''

body=""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: spaces

Copy link
Contributor

@itay itay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good - can we squash these into one change and then @shakeelmohamed can merge?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants