-
Notifications
You must be signed in to change notification settings - Fork 13
Object complete handler #362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Object complete handler #362
Conversation
…is closed before we fire customer onCompleted events. This is specific to read jobs. Needs implementing for both read ans write.
…d before we fire customer onCompleted events.
… the right number of times.
…added to the right job part tracker.
…right job part tracker.
…bject completion handler.
…ompletion handlers first.
… correct object part tracker.
…into object_complete_handler
…into object_complete_handler
…into object_complete_handler
| private final JobPartTracker internalJobPartTracker; | ||
|
|
||
| protected JobPartTrackerDecorator(final List<Objects> chunks, final EventRunner eventRunner) { | ||
| clientJobPartTracker = JobPartTrackerFactory.buildPartTracker(Iterables.concat(getAllBlobApiBeans(chunks)), eventRunner); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is Iterables.concat required here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't know. I just copied that from what was there already. I'll see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would appear not
This pull request is to address https://jira.spectralogic.com/browse/JSDK-165: Our ObjectCompleted Handler must run first
Basically, this moves firing events into the JobImpl base class, which uses a wrapper to create 2 JobPartTracker's: 1 used to fire events we register to close channels we open when Job.transfer is called; the other to fire events customers register for.
Most of this pull request is a set of integration tests. Because the nature of the problem we're solving is non-determinism in firing events, we can't rely solely of having event handlers fire in the expected order in the tests, because we don't know if firing in the right order is deterministic or not. So, we check that the JobPartTrackers have the correct number of event handlers, internal vs. client, then inject an interceptor to ensure that we're calling the event handlers in the right order.