I have sendRequest using RPCManager in smartclient. but I have to structure chaining execution. I read on internet about jQuery deferred and promise function. But I wonder whether smartclient support execution in sequential task.
Thank you.
queueing may be what are you looking for?
For example:
RPCManager.startQueue();
grid.updateData(record1, function(dsResponse, data, dsRequest){/*callback1*/});
grid.updateData(record2, function(dsResponse, data, dsRequest){/*callback2*/});
RPCManager.sendQueue(function(responses){/*finalCallback*/});
will execute the updates sequentially, in a single request, and the callbacks will be executed sequentially:
callback1
callback2
finalCallback
Related
I'm using DolphinDB subscribeTable but the error occurs:
I’d like to know what is wrong with my code. I wanted to subscribe to stream tables in DolphinDB and the code is:
csEngine1=createCrossSectionalEngine(name=sTb_Cs + "_eng",
dummyTable=objByName(sTb_join12),
keyColumn=`symbol,
triggeringPattern="perRow",
useSystemTime=false, timeColumn=`TimeStamp)
subscribeTable(tableName=sTb_join12, actionName="do"+sTb_Cs, offset=-1, handler=append!{csEngine1}, msgAsTable=true, hash=5, reconnect=true)
The UDF handler of another subscription to sTb_join12 also queries csEngine1.
def append_plan (csEngine1, candidates2, strategy, msg){
subscribeTable(tableName=sTb_join12, actionName="do" +strategy, offset=-1, handler=append_plan {csEngine1, candidates2, strategy}, msgAsTable=true, hash=6, reconnect=true)
Please tell why the error occurs and how I can fix it.
The problem is that the parameter in your function (append_plan in this case) was not mutable. With an immutable parameter, the object (csEngine1) will be set to readOnly when calling the function. If another thread writes this object (as shown in your first subscription), it will report the error.
Solution #1
Pass the same hash value in the two subscribeTable functions that subscribe to sTb_join12. With the same hash value, the two subscription tasks will be processed in the same thread in turn, which avoids concurrency and error reporting.
Solution #2
Simplify the two subscribeTable functions into one statement. ‘append!’ the cross-section engine with udf, and then continue with the above process to ensure the append operation and select query to the table CSEngines1 are sequentially processed. You can refer to the following example:
tradesCrossEngine008=createCrossSectionalEngine(name="tradesCrossEngine008", dummyTable=objByName(sTc_join12_testSTR), keyColumn=`Symbol, triggeringPattern=`perRow, useSystemTime=false, timeColumn=`TimeStamp)
def append_plan(msg){
getStreamEngine("tradesCrossEngine008").append!(msg)
select Symbol, rank(left_v1+left_v2) as rmk from getStreamEngine("tradesCrossEngine008")
}
subscribeTable(tableName=sTc_join12_testSTR, actionName="tradesCrossEngine008", offset=0, handler=append_plan, msgAsTable=true, hash=9, reconnect=true)
I am working on an orchestration layer Microservice where I need to call a few APIs of different microservices in parallel. For that I am making use of subscribeOn(Schedulers.parallel) and subscribing to each response in Mono.zip. For example:
Mono<A> a = service1.api().subscribeOn(Schedulers.parallel());
Mono<B> b = service2.api().subscribeOn(Schedulers.parallel());
Mono<C> c = service3.api().subscribeOn(Schedulers.parallel());
return Mono.zip(a,b,c);
Now AFAIK, this zip will fail if any of the a, b OR c completes with an error. Assume that something went wrong in the third call, I want to handle this case in such a way that any operation done by service1.api() and service2.api() could be reverted, i.e. rolled-back like a transaction.
I apologize for any wrong statement I've made as I am a bit new in Spring WebFlux. Thanks for all the help in advance.
I believe there is no such provision to rollback individual calls. You can make use of Mono.zipDelayError to let complete the valid calls except the one which could fail. After that, on error return you can go for individual transaction rollback with explicitly implementing the same.
I build the reactive pipeline like this on netty server with spring web-flux:
someService.getSettings(key) //Mono<Settings>
.filter(Settings::isEnabled)
.switchIfEmpty(Mono.error(
new Exception("Setting is disabled.")
)).then(/*Mono representing API fetch*/ someApi.fetch(param));
As per my understanding, whenever the Settings::isEnabled would return false, the pipeline would be empty and I will get a Mono representing error. However, this behavior does not happens. My someApi.fetch(param) call always fires without the filter Mono being completed. So even if Settings::isEnabled is false or true, someApi.fetch(param) is always fired without completion of Mono.filter.
How do I make sure that error is thrown if filter returns empty Mono and the fetch call happens only when I have checked that the setting is not disabled?
this is still java: this call to someApi.fetch(param) is not done inside a lambda, so it can't be lazy. the moment the execution reaches the then line, your fetch method is called. the Flux.defer operator is tailor-made to wrap that call and make it lazy.
I am using C# to call BAPI to communicate with SAP. I am new to this topic so I want to clarify some of the concept.
Q1: If I call BAPI_GOODSMVT_CREATE, should I check RETURN table or MAT_DOC field of items table to see whether it is succeed or failed?
Q2: If it is failed, need I call BAPI_TRANSACTION_ROLLBACK, or just ignore it(because without BAPI_TRANSACTION_COMMIT, data will not be saved)?
Q3: I found sometimes, even if there is error message, if I continue call BAPI_TRANSACTION_COMMIT, the data will be saved. But sometimes it won't.
Thanks in advance.
Check RETURN table. If it's OK, issue a BAPI_TRANSACTION_COMMIT with the WAIT flag. If it's not OK, issue a BAPI_TRANSACTION_ROLLBACK.
Check RETURN from BAPI_TRANSACTION_COMMIT as there may be errors there as well (for example a database update issue).
Ad Q1 In that particular case I'd rather check if material document number is returned in MAT_DOC. This way you don't rely on return messages. If a material document is returned, it means BAPI call was successful irrespective of messages. I find BAPIs implementation of handling return message quite inconsistent. Some BAPIs return a success message, some don't.
Ad Q2, Q3 Always call BAPI_TRANSACTION_COMMIT or BAPI_TRANSACTION_ROLLBACK after a BAPI call depending on result. BAPI_TRANSACTION_COMMIT and BAPI_TRANSACTION_ROLLBACK not only execute commit / rollback work but also call BUFFER_REFRESH_ALL function.
I am trying to add a WFP filter while holding an NDIS RW lock, but FwpmEngineOpen or FwpmTransactionBegin functions fail.
Is there a limitation that prevents these functions to work at Dispatch level?
Thanks!
The documentation for FwpmEngineOpen0 states that the requirement is IRQL == PASSIVE_LEVEL, so it won't work in DISPATCH_LEVEL.