When running a Corda flow, I receive the following error:
java.lang.IllegalStateException: No transaction in context
How can I solve this issue?
This issue is likely caused by a failure to annotate a function called from within a flow with the #Suspendable annotation. This could either be FlowLogic.call, or a function called from within FlowLogic.call (e.g. SignTransactionFlow.checkTransaction if you are overriding this function as part of a call to CollectSignaturesFlow).
If you run flow tests with the following command line flag:
-Dco.paralleluniverse.fibers.verifyInstrumentation=true
Then the missing annotation will be highlighted if it causes an error. However, this will slow down the running of the tests.
Related
We have an application that makes use of Spring Kafka's non blocking retries via the RetryableTopic annotation.
We are in the middle of upgrading spring-kafka from 2.8.4 to 2.9.0.
We have several SpringBootTests that makes use of EmbeddedKafka. Each of these tests are marked with DirtyContext and AutoConfigureMockMvc
After upgrading, the first test would run fine, but the later test would fail to start the application with
Constructor threw exception; nested exception is java.lang.IllegalStateException: Only one 'RetryTopicConfigurationSupport' is allowed
I understand that the RetryTopicConfigurationSupport tries to ensures only one instance of itself is ever instantiated. So in the use case of running multiple unit tests, which includes multiple different SpringBootTests, how do we avoid hitting this problem?
I have tried marking the context dirty, but of course that didn't solve the problem as RetryTopicConfigurationSupport is using a static variable to track whether it has been instantiated before or not.
I have tried NOT marking the ContextDirty, but the later tests would fail to start the application because the Port is already in use.
Appreciate any advise!
Looks like this problem has been addressed in spring-kafka 3.0 and backported to 2.9.3
https://github.com/spring-projects/spring-kafka/issues/2477
Suppose we have the following situation:
launch_kernel_a<<<n_blocks, n_threads>>>(...);
launch_kernel_b<<<n_blocks, n_threads>>>(...);
cudaDeviceSynchronize();
if(cudaGetLastError() != CudaSuccess)
{
// Handle error
...
}
My understanding is that in the above, execution errors occurring during the asynchronous execution of either kernel may be returned by cudaGetLastError(). In that case, how do I figure out which kernel caused the error to occur during runtime?
My understanding is that in the above, execution errors occurring during the asynchronous execution of either kernel may be returned by cudaGetLastError().
That is correct. The runtime API will return the last error which was encountered. It isn't possible to know from which call in a sequence of asynchronous API calls an error was generated.
In that case, how do I figure out which kernel caused the error to occur during runtime?
You can't. You would require some kind of additional API call between the two kernel launches to determine the error. The crudest would be a cudaDeviceSynchronize() call, although that would serialize the operations if they actually did overlap (although I see no stream usage so that is probably not happening here).
As noted in comments -- most kernel runtime errors will result in context destruction, so if you got an error from the first kernel, the second kernel will abort or refuse to run anyway and that is probably fatal to your whole application.
Consider the following basic structure of a Parallel Convoy pattern in BizTalk 2016. It is a Parallel Action with 2 active Receive shapes. Combined with a single correlation set that is being initialized by both active receives.
Now my issue arose when I want to have separate exception handling, one for the left receive, and one for the right receive. So I've put a scope around the left receive (Scope_1) with a timeout. And I've wrapped that scope in another scope (Scope_3), to catch the timeout exception.
Now for some reason this isn't allowed and I get back "fatal error X1001: unknown system exception" at build time.
However, if I wrap the scope_3 around both active receives, it's building successfully:
What's the significant difference here for BizTalk to not allow separate timeout exception handling in this scenario?
By the way:
It doesn't matter what type of exception I'm trying to catch, or if all my scopes are a Long Running transaction or not, the occurrence of the error is the same.
If I make a separate correlation set for each receive, the error does not occur, but of course that's not what I want because it wouldn't make it a parallel convoy then.
Setting scopes to synchronized does not affect the behavior.
The significant difference is that the Orchestration will start up when it receives the first message, which may not be the scope_1. So the timer would not be started in that scenario. And if it was scope_1, well it won't time out as you have received it, but it won't be timing out for scope_2.
Having the timer around both, does set the timeout in both scenarios.
What you could do is have the timeout scope as per your second example and set a flag to indicate which one was received, and use that in your exception block.
The other options is a first Receive shape that initializes the correlation set, and then a second receive after it that has the following correlation and have the timeout on that.
First, i am able to replicate your issue.
Although visual studio reported this as an unknown system exception but for me it looks unreachable code detected based the receive shape that is inside the scope (scope_3) that is trying to initialize your correlation. So there's a possibility that you wont be able to initialize the correlation same way your left scope (scope_2) does if your main scope (scope_1) is having some exceptions.
The only way I can think is to use using different correlation sets, you can set your send port to follow on these correlation set.
Without using correlation sets, this should not give error during build time. For me this is considered to be an MS bug, VS should be able to point out the unreachable code detected, not fatal error:
I am trying to run an external code in OpenMDAO 2 that outputs some minor error messages as part of it's run process in windows shell. These error messages does not affect the results of the code and the code runs itself normally. However OpenMDAO raises a fault and stops whenever it detects these error messages. Is it possible for OpenMDAO to ignore such situation and continue running the analysis? I have tried setting fail_hard option to false, but it doesn't seem to change the behavior except that OpenMDAO raises analysis error instead of run-time error.
We can implement a feature to let you specify allowable return codes.. as long as you can enumerate which return codes are not errors, I think this will solve your problem?
I've updated HereMaps JavaScript from 2.2.4 to 2.5.3 and the map has stopped working on Chrome (version 31.0.1650.57 m). Firefox and IE work as before.
On the console I see the message many times
Coroutine 'nokia.maps.map.render.p2d.Engine#_renderCo' aborted abnormally with exception base.js:158
TypeError: Cannot read property 'body' of undefined
Does anyone have a hint of what might be wrong?
Thanks.
It is very difficult to answer your specific problem without seeing your code, but I am able to produce a similar error which may help you track down your issue.
If you are getting multiple error messages, then it is likely that the JavaScript library itself is calling something periodically. From the text of the error it likely that the library is running a Coroutine, which is usually used for threading within the application.
The error I can produce is in a callback - if I add an overlay to the map, and deliberately try to access a non-existent property within my code I can get:
Coroutine 'nokia.maps.map.render.p2d.Engine#_renderCo' aborted abnormally with exception base.js:158
TypeError: Cannot read property 'bar' of undefined
This was because I added a typo as follows:
I changed the reference from foo.something.bar in the callback to foo.does_not_exist.bar. So I guess somewhere in your callbacks you are referencing foo.something.body in your callback - it could be in a listener for example.
Another possibility, is that you are switching directly to Display.SATELLITE when you are creating the map - this is no longer allowed:
Taken from the News feed on developer.here.com:
Breaking changes with 2.5.3
The new rendering engine requires the map to be initialized
asynchronously. If you want to change the center, zoom level or the
base map type the API now requires the application to wait for the
"displayready" event to be fired. This event is only fired once.
Please refer to the developer's guide (section "Beyond the Basic Map Application
") for details.