FwpmEngineOpen fails at dispatch level - dispatch

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.

Related

Is there any way to provide transaction rollback in Mono.zip?

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.

Apache Flink - exception handling in "keyBy"

It may happen that data that enters Flink job triggers exception either due to bug in code or lack of validation.
My goal is to provide consistent way of exception handling that our team could use within Flink jobs that won't cause any downtime in production.
Restart strategies do not seem to be applicable here as:
simple restart won't fix issue and we fall into restart loop
we cannot simply skip event
they can be good for OOME or some transient issues
we cannot add custom one
try/catch block in "keyBy" function does not fully help as:
there's no way to skip event in "keyBy" after exception is handled
Sample code:
env.addSource(kafkaConsumer)
.keyBy(keySelector) // must return one result for one entry
.flatMap(mapFunction) // we can skip some entries here in case of errors
.addSink(new PrintSinkFunction<>());
env.execute("Flink Application");
I'd like to have ability to skip processing of event that caused issue in "keyBy" and similar methods that are supposed to return exactly one result.
Beside the suggestion of #phanhuy152 (which seems totally legit to me) why not filter before keyBy?
env.addSource(kafkaConsumer)
.filter(invalidKeys)
.keyBy(keySelector) // must return one result for one entry
.flatMap(mapFunction) // we can skip some entries here in case of errors
.addSink(new PrintSinkFunction<>());
env.execute("Flink Application");
Can you reserve a special value like "NULL" for the keyBy to return in such case? Then your flatMap function can skip when encounter such value?

Best practice for BAPI commit and rollback?

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.

Calling gracefulStop Singleton Actor

For testing purposes, I'm trying to restart a singleton actor (created using ClusterSingletonManager and ClusterSingletonProxy). However, the documentation for gracefulStop says:
IMPORTANT NOTICE: the actor being terminated and its supervisor being informed of the availability of the deceased actor’s name are two distinct operations, which do not obey any reliable ordering. Especially the following will NOT work:
def receive = {
case msg =>
Await.result(gracefulStop(someChild, timeout), timeout)
context.actorOf(Props(...), "someChild") // assuming that that was someChild’s name, this will NOT work
}
Does anyone know a way around this? Please don't tell me to use Thread.sleep. A blocking loop that checks for the name availability would be OK, though a less hack-ish way would be preferable. If that's the only way, how can one check if an actor name is available?

Smartclient have any deferred and promise

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