Skip to content
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

Use Jobs client #792

Open
abroekhuis opened this issue Nov 7, 2019 · 5 comments
Open

Use Jobs client #792

abroekhuis opened this issue Nov 7, 2019 · 5 comments

Comments

@abroekhuis
Copy link

Hi all,

I'm trying to write a lambda function that processes jobs. While I can get an example to subscribe to the job topics, and as such write my own jobs handler, I am wondering if there is already some solution that has some code to solve this.
I've also seen that the new (v2) Java SDK has a JobsClient, is there an easy way to use this one myself? (https://github.com/awslabs/aws-iot-device-sdk-java-v2/blob/master/sdk/src/main/java/software/amazon/awssdk/iot/iotjobs/IotJobsClient.java)

@timmattison
Copy link
Contributor

It looks like this needs some more in the SDK but I'm going to see if I can get a PR put together to handle this - aws/aws-iot-device-sdk-java-v2#24 - and then we can discuss the actual Lambda function.

@abroekhuis
Copy link
Author

Thanks for the quick reply, good to see things are picked up :D.

I'm quite new to Greengrass and the different IoT API's, so I might be missing something obvious as well.
But just some thoughts I had about this issue, and the IotJobsClient of the new SDK. The SDK uses a plain connection and uses topics directly, does this make sense for a Lambda function?
Lambda functions need to correct subscription (luckily there are wildcards, so using $aws/things/$thingname/jobs/# works fine), and input is handled directly. Doesn't that conflict with each other, eg, when creating an explicit subscription, aren't there actually 2 clients listening? The first one being the Greengrass SDK, and the second one the Java SDK (user created).

I am now looking into changing the JobsClient code to use the CCD method of handling in and outputs. From that point of view I don't see any direct need to use the SDK as-is, but I can imagine there are more benefits of having the SDK available inside Lambda functions.

@timmattison
Copy link
Contributor

Using a connection to IoT Core inside a Greengrass function is possible, but not recommended. Doing that means Greengrass doesn't handle any of the buffering or disconnection logic.

It's better to use a library that you can route the messages to from your handlers directly. In order to support that though it looks like the AWS SDK needs some modification. I'm working to see what is involved there.

You referenced CCD, do you mean CDD? If so, that'd be very nice. I'd like to have that integrated into the baseline library so people could incorporate it easily.

@timmattison
Copy link
Contributor

It looks like this is a little more involved than a one day solve on my part. I've communicated this to our teams. If you DM me on Twitter I can keep you on top of the progress.

@abroekhuis
Copy link
Author

No problem, I'm going to try to port the Jobs client to the current cdd skeleton. If you are interested in that solution, please let me know.
I've sent you a PM on Twitter, Thanks for the effort!

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

No branches or pull requests

2 participants