While doing GetComponentParts I am getting following error, to be specific it reporoduces while i do import in continuous loop while handling multiple messages in my WCF application
The composition produced a single composition error. The root cause is provided below. Review the CompositionException.Errors property for more detailed information.
1) The composition failed because it did not complete within '100' iterations. This is most likely caused by a cycle in the dependency graph of a part which is marked with a non-shared creation policy.
One more thing I cant locate CompositionException.Errors to find the root cause.
Please suggest what workaround possible, as i am not getting a single thread on the net suggesting any way...
Many Thanks
Since this is working most of the time, it is probably a threading issue which is corrupting MEF's internal state and causing this error.
When using a CompositionContainer from multiple threads, you need to create it with the isThreadSafe parameter set to true, and avoid calling methods which modify what is available - such as Compose, ComposeParts, or AddExportedValue.
Methods which are safe to call are the GetExport and SatisfyImports methods.
Related
I'm practicing with the vulkan API, Yesterday I wasted almost the entire day in implementing secondary buffers for use different fragment shaders on different objects.
Big issue was an error "segmentation fault" in call to vkCmdDrawIndexed(). For the moment this is a matt black box for me, I don't find a method to investigate the origin of the issue. Although the vulkan API has validation layers for debug, it is already complicate without these ones. I suspect that the error is in the code for the creation secondary CommandBuffers.
Leaving out these problems due to my not knowing, I accidentally found that the code works the same with only the primary commandbuffer and multiple calls to vkCmdBindPipeline():
vkBeginCommandBuffer(primaryCommandBuffer...);
vkCmdBeginRenderPass(...);
vkCmdBindPipeline(...pipeline_things_a);
vkCmdBindDescriptorSets(...);
vkCmdBindVertexBuffers(...);
vkCmdBindIndexBuffer(...);
vkCmdSetViewport(...);
vkCmdSetScissor(...);
draw_things_a(...) {... vkCmdDrawIndexed(...) ...}
vkCmdBindPipeline(...pipeline_things_b);
vkCmdBindDescriptorSets(...);
vkCmdBindVertexBuffers(...);
vkCmdBindIndexBuffer(...);
vkCmdSetViewport(...);
vkCmdSetScissor(...);
draw_things_b(...) {... vkCmdDrawIndexed(...) ...}
vkCmdEndRenderPass(primaryCommandBuffer);
vkEndCommandBuffer(primaryCommandBuffer);
I'm outside regular learning path, so my question can be an obvious error for the most, but I ask:
Is it an error the multiple call of vkCmdBindPipeline() in primary command buffer?
No, that's not an error. You can do arbitrary calls for e.g. binding pipelines within a single command buffer. In general you can call all commands beginning with vkCmd arbitrarily in a single command buffer as much as you want.
As you may know, it is pretty easy to have active code of a class containing syntax errors (someone activated the code ignoring syntax warnings or someone changed the signature of a method the class calls, for instance).
This means that also dynamic instantiation of such a class via
CREATE OBJECT my_object TYPE (class_name).
will fail with an apparently uncatchable SYNTAX_ERROR exception. The goal is to write code that does not terminate when this occurs.
Known solutions:
Wrap the CREATE OBJECT statement inside an RFC function module, call the module with destination NONE, then catch the (classic) exception SYSTEM_FAILURE from the RFC call. If the RFC succeeds, actually create the object (you can't pass the created object out of the RFC because RFC function modules can't pass references, and objects cannot be passed other than by reference as far as I know).
This solution is not only inelegant, but impacts performance rather harshly since an entirely new LUW is spawned by the RFC call. Additionally, you're not actually preventing the SYNTAX_ERROR dump, just letting it dump in a thread you don't care about. It will still, annoyingly, show up in ST22.
Before attempting to instantiate the class, call
cl_abap_typedescr=>describe_by_name( class_name )
and catch the class-based exception CX_SY_RTTI_SYNTAX_ERROR it throws when the code it attempts to describe has syntax errors.
This performs much better than the RFC variant, but still seems to add unnecessary overhead - usually, I don't want the type information that describe_by_name returns, I'm solely calling it to get a catchable exception, and when it succeeds, its result is thrown away.
Is there a way to prevent the SYNTAX_ERROR dump without adding such overhead?
Most efficient way we could come up with:
METHODS has_correct_syntax
IMPORTING
class_name TYPE seoclsname
RETURNING
VALUE(result) TYPE abap_bool.
METHOD has_correct_syntax.
DATA(include_name) = cl_oo_classname_service=>get_cs_name( class_name ).
READ REPORT include_name INTO DATA(source_code).
SYNTAX-CHECK FOR source_code MESSAGE DATA(message) LINE DATA(line) WORD DATA(word).
result = xsdbool( sy-subrc = 0 ).
ENDMETHOD.
Still a lot of overhead for loading the program and syntax-checking it. However, at least none additional for compiling descriptors you are not interested in.
We investigated when we produced a dependency manager that wires classes together upon startup and should exclude syntactically wrong candidates.
CS includes don't always exist, so get_cs_name might come back empty. Seems to depend on the NetWeaver version and the editor the developer used.
If you are certain that the syntax errors are caused by the classes’ own code, you might want to consider buffering the results of the syntax checks and only revalidate when the class changed after it was last checked. This does not work if you expect syntax errors to be caused by something outside those classes.
What is a "suitable guard" and what does it look like?
Linked this question because it refers to the same compiler message and the answer mentions a guard but not how to create one. Looked through the AspectJ docs but did not find and answer there.
This Lint warning is usually switched off in AJDT (AspectJ Development Tools) within Eclipse, but you can activate it as a warning or even error like this (I had to do it to actually see it at all when trying to reproduce your issue):
You can just ignore the Lint warning because basically it only says that there is no way for certain pointcuts to populate the thisJoinPoint object lazily during runtime because the pointcut has no dynamic component like if(), cflow() or similar, which is actually good news because it means that all your joinpoints can be determined statically during compile/weave time and are thus faster than dynamic pointcuts. On the other hand, the warning says that the tjp object always has to be created because for some reason it is also always needed during runtime and thus cannot be instantiated lazily.
I am calling a ASYNC method in an MVC4 application. This method has to call a dozen or so other methods, which are nested. My issue is that if any of these nested methods break, it passes the error to the parent method. Since they are all nested, it just keeps passing up the chain returning to the HTTP context the generic error message.
Since I have so many nested methods, I have no clue how to find more information on the error. Even a simple line that broke would be extremely helpful.
Right now I am resorting to breaking every line to see which ran last before it stop responding. This Method alone, with it's nested methods, are over 2000 lines of code. As you can tell, this is a very un-effective way at debugging.
Any help at a better way of finding out where a ASYNC method actually broke, when in nested methods, would be extremely helpful. I really want to avoid doing a Try/Catch on every method I have.
-- Edit --
This has been answered. I put my solution below and will mark it as answered in two days, per StackOverflow restrictions.
Apparently if I put a Try/Catch on the first call inside my Action Method it at least gives me the line in the stack trace. Once noting this, I added ELMAH and inspected my error log when throwing a generic exception. It appears that the line gets passed back to ELMAH also.
While this is not nearly as nice as normal exception breaking in visual studio, it allows me to easily put a breakpoint on that exact line to see what is happening.
Unfortunately, asynchronous "stack traces" do not work very well out of the box.
You can do your own tracing using a technique I describe in this blog post. Or you could try installing my async diagnostics package which adds the asynchronous "stack trace" to the exception's Data property (note: not logged by default in ELMAH). However, this package is not yet production-ready, so I recommend uninstalling before deploying.
I'm working on building out a set of common libraries for use with an embedded instances of the Lua interpreter (the target audience is users of a particular product). Assume I have no access to changing the capabilities of the Lua executables, and have only the basic standard Lua libraries (math, string, ..., exception is no io).
What is an idiomatic way for handling runtime errors in the pure Lua libraries?
I've considered returning nil, but this doesn't signal what went wrong, especially if the error occurred somewhere deeply nested. My next thought is to return two values, nil and an error code or description. I've also considered a set of global functions similar to the Windows API's GetLastError (and corresponding, SetError).
What do you use? What do you see as the various pros/cons to the various approaches? Should I consider something more radical like wrapping everything in pcall and intentionally indexing userdata to cause an error?
Errors that cannot be recovered from should just abort execution. For those, call error. Otherwise, returning nil or false and an error message is the standard Lua way.