I'm using the samples for the AwsFlowFramework, specifically helloworld and fileprocessing. I have followed all the setup instructions given here. All the client classes are successfully created with the aspect weaver. It all compiles and runs.
But trying to do .get on a Promise within an asynchronous method doesn't work. It waits forever and a result is never returned.
What am I doing wrong?
In particular the helloworld sample doesn't have any asynchronous method nor does it attempt to do a .get on a Promise. Therefore, it does work when copied outright and I can see in the activities client the "hello world" message printed. Yet, if I create a stub Asynchronous method to call get on the Promise<Void> returned by printHello, the client of the activities is never called and so the workflow waits forever. In fact the example works if I set the returned promise to a variable. The problem only arises if I try to call .get on the Promise. The fileprocessing example which does have asynchronous methods doesn't work.
I see the workflows and the activity types being registered in my aws console.
I'm using the Java SDK 1.4.1 and Eclipse Juno.
My list of unsuccessful attempts:
Tried it with Eclipse Indigo in case the aspect weaver does different things.
Made all asynchronous methods private as suggested by this question.
If I call .isReady() on the Promise this is always false even if I call it after I see the "helloworld" message printed (made certain by having a sleep in between). This leads me to think that Promise.get blocks the caller until Promise.isReady is true but because somehow this is never true, the client is not called and the workflow waits forever.
Tried different endpoints.
My very bad. I had a misconfiguration in the aop.xml file and so the load aspectj weaving for the remote calls was not correct.
Related
I'm using Vertx 3.5.0 and very new to it. I'm trying to cancel the code execution when a client cancels their request.
Currently it's setup to where the first thing we do is deploy a verticle to run an HttpServer, and we add all of our Routes to the Router. From here we have a handler function per route. Inside this handler I'm trying this:
routingContext.request().connection().closeHandler({
//execute logic for ending execution
});
This is the only method I've seen that actually catches the closing of the connection, but the problem is it doesn't execute the handler early enough in the eventloop. So if I have any logs in there it will look like:
...[vert.x-eventloop-thread-0].....
...[vert.x-eventloop-thread-0]..... (Let's say I cancelled the request at this point)
...[vert.x-eventloop-thread-0].....
...[vert.x-eventloop-thread-0]..... (Final log of regular execution before waiting on asynchronous db calls)
...[vert.x-eventloop-thread-0]..... (Execution of closeHandler code)
I'd like for the closeHandler code to interrupt the process and execute essentially when the event actually happens.
This seems to always be the case regardless of when I cancel the request so I figure I'm missing something about how Vertx is handling the asynchronousity.
I've tried executing the closeHandler code via a worker verticle, inside the blockingHandler from the Router object, and inside the connectionHandler from the HttpServer object. All had the same result.
The main code execution is also not executed by a worker verticle, just a regular one.
Thanks!
It seems you misunderstand what a closeHandler is. It's a callback method, that Vert.x invokes when the request is being closed. It is not way to terminate the request early.
If you would like to terminate request early, one way is to use response().close() instead.
As a footnote, I'd like to mention that Vert.x 3.5.0 is 4 years old now, and you should be upgrading to 3.9, or, if you can, to 4.0
In a chat app, if I add a new message to the messages collection, I also need to update that particular chat's document in another collection to show the last message and the time when it was sent. Right now I am triggering a cloud function every time a new message comes, in order to update the metadata for the chat. Am I doing the right thing or would it be more appropriate to use Batched writes instead?
There is a difference that you might be aware of when using one approach vs. the other. When using a batch write, according to the official documentation:
You can execute multiple write operations as a single batch that contains any combination of set(), update(), or delete() operations. A batch of writes completes atomically and can write to multiple documents.
This means that those simultaneous updates that are made in this atomic way, either all updates succeed or all updates fail.
In case you are using a function that is triggered once a message is sent, it means that you are performing two separate actions. The first one is to send a message and the second one is to update some metadata once the message is successfully sent. In this case, you can send a message but your function may fail, according to the official documentation:
By default, without retries enabled, the semantics of executing a background function are "best effort." This means that while the goal is to execute the function exactly once, this is not guaranteed.
This are the reasons why background functions fail to complete:
On rare occasions, a function might exit prematurely due to an internal error, and by default the function might or might not be automatically retried.
More typically, a background function may fail to successfully complete due to errors thrown in the function code itself. Some of the reasons this might happen are as follows:
The function contains a bug and the runtime throws an exception.
The function cannot reach a service endpoint, or times out while trying to reach the endpoint.
The function intentionally throws an exception (for example, when a parameter fails validation).
When functions written in Node.js return a rejected promise or pass a non-null value to a callback.
The workaround in this case, is to use retry to handle transient errors.
Meteor's documentation states:
In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node
Do they actually mean?
A) the server is running multiple threads in parallel (which seems unusual within the Node.js ecosystem)
or
B) There is still only a single thread within an evented server and each request is processed sequentially, at least until it makes calls to resources outside the server - like the datastore, at which point the server itself is handling the callbacks while it processes with other requests, so you don't have to write/administer the callbacks yourself.
Brad, your B is correct.
Meteor uses fibers internally. As you said, there's only one thread inside an evented server, but when you do (eg) a database read, Fibers yields and control quickly gets back to the event loop. So your code looks like:
doc = MyCollection.findOne(id);
(with a hidden "yield to the event loop, come back when the doc is here") rather than
MyCollection.findOne(id, function (err, doc) {
if (err)
handle(err);
process(doc);
});
Error handling in the fiber version also just uses standard JavaScript exceptions instead of needing to check an argument every time.
I think this leads to an easier style of code to read for business logic which wants to take a bunch of actions which depend on each other in series. However, most of Meteor's synchronous APIs optionally take callbacks and become asynchronous, if you'd like to use the async style.
http://docs.meteor.com/#meteor_methods
I have tried it in publish.js in my server folder.
I am successfully calling Meteor.apply and attempting the server call from the client. I always get an undefined response.
Calling Meteor.methods on the server is correct. That will define remote methods that run in the privileged environment and return results to the client. To return a normal result, just call return from your method function with some JSON value. To signal an error, throw a Meteor.Error.
On the client, Meteor.apply always returns undefined, because the method call is asynchronous. If you want the return value of the method, the last argument to apply should be a callback, which will be passed two arguments: error and result, in the typical async callback style.
Is your server code actually getting called? You can check that by updating the DB in the method and seeing if the client's cache gets the new data, or calling console.log from inside the method body and looking at the output of the "meteor" process in your terminal.
There are several places I can define my Meteor.methods() (with pro's and con's):
On the server only - when the client calls the method, it'll have to wait for the server to respond before anything changes on the client-side
On the server, and uses a stub on the client - when the client calls the method, it will execute the stub method on the client-side, which can quickly return a (predicted) response. When the server comes back with the 'actual' response, it will replace the response generated by the stub and update other elements according.
The same method on both client and server - commonly used for methods dealing with collections, where the method is actually a stub on the client-side, but this stub is the same as the server-side function, and uses the client's cached collections instead of the server's. So it will still appear to update instantly, like the stub, but I guess it's a bit more accurate in its guessing.
I've uploaded a short example here, should you need a working example of this: https://gist.github.com/2387816
I hope some will find use of this addition, and this doesn't cloud the issue that methods are primarily intended to run on the server as debergalis has explained.
Using Meteor.methods() on the client is useful too. (look for "stub" in the Meteor.call() section too...)
This allows the client to (synchronously) simulate the expected effect of the server call.
As mentioned in the docs:
You use methods all the time, because the database mutators (insert,
update, remove) are implemented as methods. (...)
A separate section explaining use of stubs on the client might ease the understanding of methods calls on the server.
I am creating a node.js module which communicates with a program through XML-RPC. The API for this program changed recently after a certain version. For this reason, when a client is created (createClient) I want to ask the program its version (through XML-RPC) and base my API definitions on that.
The problem with this is that, because I do the above asynchronously, there exists a possibility that the work has not finished before the client is actually used. In other words:
var client = program.createClient();
client.doSomething();
doSomething() will fail because the API definitions have not been set, I imagine because HTTP XML-RPC response has not returned from the program.
What are some ways to remedy this? I want to be able to have a variable named client and work with that, as later I will be calling methods on it to get information (which will be returned via a callback).
Set it up this way:
program.createClient(function (client) {
client.doSomething()
})
Any time there is IO, it must be async. Another approach to this would be with a promise/future/coroutine type thing, but imo, just learning to love the callback is best :)