If I do something like this:
ddbClient.query(someParams).promise()
I will frequently (or possibly always) get this error:
Error: ValidationException: Request object already used
It seems to be because the promise and query have already launched by the time .promise() is called, but that works just fine with the ddb client connecting directly to the database rather than going through dax.
Seems like this may be a bug?
This problem is caused by using both a callback and the .promise() method, like this:
ddbClient.query(someParams, (error, result) => { something } ).promise();
The problem is that every call in the DynamoDB API returns an object of type AWS.Request. The actual HTTP request gets sent only when you call the send() method. But passing a callback implicitly calls send(), and calling promise() implicitly calls it again. You can only call send() once.
The callback has to be turned into a .then() call.
Related
I've never took the time/chance to really understand the scope of Deps.autorun... so here I am again with the same problem that had bothered me many times (previously, I always found a workaround and bypass the issue)... anyways, basically, I have a function defined on the server side:
serverFunc = function() {}
and on the client side, I do
Deps.autorun(function() { var test = serverFunc(); }
I get error message say serverFunc is not defined.
Can someone kindly help me understanding why this is happening?
Thanks so much!
Deps.autorun() always runs once, then reruns the function whenever any of the dependencies that are tracked changes. These dependencies usually need to be set up as Meteor reactive data sources. A simple function being undefined on the client and then defined on the server isn't enough to retrigger.
If you want functions defined only on the server to be called from the client, you have to do two things:
On the server, put the function in Meteor.methods
On the client, use Meteor.call
Otherwise, a function defined only on the server does not exist on the client, and calling it on the client will throw an error as calling an undefined function.
I have following flow in my Mule app:
<flow name="UpdateStatusFlow">
<vm:inbound-endpoint path="UpdateStatusFlow" exchange-pattern="request-response"/>
<async processingStrategy="asynchronous">
<request-reply>
<vm:outbound-endpoint path="request"/>
<vm:inbound-endpoint path="reply"/>
</request-reply>
</async>
<custom-transformer class="com.example.EanTransformer"/>
</flow>
In async scope I depend on what has come to vm:inbound-endpoint and I assumed it is copy of that payload, so another copy is sent to EanTransformer which also modify payload. But it seems that no copy is made because in async flow I get already modified by EanTransformer ean code, which is not what I expected. If I add some delay in EanTransformer everything is fine, which means for me that this transformer haven't modify the message yet.
So the question is: if async scope really gets copy of the message (as it is written here: http://www.mulesoft.org/documentation/display/current/Async+Scope+Reference) or work on the same message as next components? Or am I doing something wrong?
I am using Mule 3.3.1.
If you read the referenced page further, it states that:
Even though the Async scope receives a copy of the Mule message, the payload is not copied. The same payload object(s) will be referenced by both Mule messages: the one that continues down the original flow and the one processed by the Async scope.
In other words, if the payload of your message is a mutable object
(for example a bean with different fields in it) and a message
processor in your async scope changes the value of one of the fields,
the message processors outside of the Async scope will see the changed
values.
The Async flow does not receive a Copy of the message - rather it receives the original payload. So any changes to the payload should be done before the Async flow. Here it is clearly written:
Even though the Async scope receives a copy of the Mule message, the payload is not copied. The same payload object(s) will be referenced by both Mule messages: the one that continues down the original flow and the one processed by the Async scope.
In other words, if the payload of your message is a mutable object (for example a bean with different fields in it) and a message processor in your async scope changes the value of one of the fields, the message processors outside of the Async scope will see the changed values.
If, as part of a single Meteor.call, I make two calls to the database on the server, will these happen synchronously or do I need to use a callback?
Meteor.methods({
reset: function(id) {
Players.remove(_id:id);
// Will the remove definitely have finished before the find?
Players.find();
...
}
From the docs:
In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. We find the linear execution model a better fit for the typical server code in a Meteor application.
If you read the docs on docs.meteor.com/#remove
you can find this :
Blockquote
On the server, if you don't provide a callback, then remove blocks until the database acknowledges the write and then returns the number of removed documents, or throws an exception if something went wrong. If you do provide a callback, remove returns immediately. Once the remove completes, the callback is called with a single error argument in the case of failure, or a second argument indicating the number of removed documents if the remove was successful.
Blockquote
On the client, remove never blocks. If you do not provide a callback and the remove fails on the server, then Meteor will log a warning to the console. If you provide a callback, Meteor will call that function with an error argument if there was an error, or a second argument indicating the number of removed documents if the remove was successful.
So on server side you choose if you want it to run in a sync or async way, it depends if you send a callback or not.
I'm using meteor 0.6.4.
Meteor.methods({
random: function(top){
var random = Math.floor((Math.random()*(top+1)));
return random;
}
});
It returns undefined whenever I execute
Meteor.call('random', 10);
Any ideas how I can get past this?
This is a perfectly normal behavior: server method calls in Meteor are documented to be asynchronous :
On the client, if you do not pass a callback and you are not inside a stub, call will return undefined, and you will have no way to get the return value of the method.
It means that when you ask for a Meteor.call method to execute remotely on the server, the local method call is non blocking and returns undefined immediately.
When the method has been called on the server it will send the result asynchronously to the client, so you should retrieve it using the callback pattern :
Meteor.call("myMethod", arguments..., function(error, result){
if(error){
console.log(error.reason);
return;
}
// do something with result
});
The anonymous callback function will be called on the client as soon as the server method result is sent back to the client.
There is another subtle feature in Meteor invalidating what I just said : latency compensation and methods stubs.
In case the server method call can be SIMULATED properly in the client and thus executed right away without a round-trip to the server, you can define what is called a method stub (or simulation).
A common use case for this behavior is inserting immediately in the local (client side replication subset) database some user content just posted (a comment under a blog article for example) : all the necessary data and logic is available and it makes sense to simulate server side insertion.
What happens next is that the user sees the webpage updated as soon as he submitted his content even if the server hasn't acknowledged these changes yet. (this is an example how latency compensation is implemented in Meteor).
Of course the server has final words on what gets ultimately inserted in the database, this means that when the server side twin method is executed, its actions will take precedence and replace what was inserted in the local database.
To define such method stub, you just have to define the same server method name on client code.
If the method declaration is defined in shared code (shipped both to client and server), you can test if the method call is actually a simulation by checking the isSimulation property :
Meteor.methods({
myMethod: function(arguments...){
if(this.isSimulation){
// called from the client
}
}
});
UPDATE 26/11/2014 : #steph643 commented on how the last part of my previous answer was actually wrong, here is a correction.
Note that on the server method calls can always be invoked using the synchronous syntax because server environment provides adequate blocking mechanism (fibers).
On the client however, if you return something from a method stub, it can be executed synchronously only if you're inside another stub and you can retrieve the result in a synchronous way, ie
Meteor.methods({
intermediateMethod: function(){
return " WORLD";
},
method: function(){
var result = "HELLO";
result += intermediateResult;
var intermediateResult = Meteor.call("intermediateMethod");
return result;
}
});
This behavior is a bit weird considering that Mongo collection operations (insert/update/delete) are implemented as Meteor methods and their client versions are implementing valid stubs (modification of minimongo replicated local database subset) that can be executed synchronously.
For a user application (not a driver) using WinUSB, I use WinUsb_ControlTransfer in combination with overlapped I/O to asynchronously send a control message. Is it possible to cancel the asynchronous operation? WinUsb_AbortPipe works for all other endpoints but gives an 'invalid parameter' error when the control endpoint is passed (0x00 or 0x80 as the pipe address). I also tried CancelIo and CancelIoEx but both give an 'invalid handle' error on the WinUSB handle. The only related information I could find is on http://www.winvistatips.com/winusb-bugchecks-t335323.html, but offers no solution. Is this just impossible?
Probably not useful to the original asker any more, but in case anyone else comes across this: you can use CancelIo() or CancelIoEx() with the file handle that you originally passed in to WinUsb_Initialize().
This is similar to how the documentation of WinUsb_GetOverlappedResult says:
This function is like the Win32 API routine, GetOverlappedResult, with one difference—instead of passing a file handle that is returned from CreateFile, the caller passes an interface handle that is returned from WinUsb_Initialize. The caller can use either API routine, if the appropriate handle is passed. The WinUsb_GetOverlappedResult function extracts the file handle from the interface handle and then calls GetOverlappedResult.