Discussions

News: JEXIN, Java error simulation platform, released

  1. The initial release (version 0.5) of Jexin has been completed. It is released under the Apache License 2.0. Jexin implements error simulation using exception injection. Exception injection means a method call is intercepted and a user defined exception is thrown by Jexin to simulate some error. For example, say there is a method called sendMessage that sends a message to a JMS queue. A Jexin user could configure sendMessage to throw an exception when it is called to simulate the queue being unavailable. Jexin uses Java annotations and aspects to identify methods that allow exceptions to be injected. Annotating a method with @Traceable makes it available to the Jexin user as a place an exception can be injected. The actual exception to be injected (if any) is determined at runtime using the Jexin web application. The Jexin web application must be installed on a server that is accessible to the applications being manipulated. Only one server instance is needed to work with several applications and/or environments. Integrating Jexin with your application is straightforward. A single object (the TraceServer) must be running in the application being manipulated. TraceServer configuration is fairly simple and integrates well with Spring. The methods you want to allow errors to be simulated in must then be annotated with @Traceable. That's all there is to it. Jexin includes a sample application that you can use to try it out. You can also check out the Getting Started and User's Guide pages on the Jexin site.
  2. JXInsight has had this feature implemented for sometime via its Diagnostics Open API and corresponding Dump, Diagnostic, Frame, and Throw(Before|After) aspect extensions. Our solution goes even further by recording comprehensive object state (min-heap dumps) associated with the target object, arguments, thread state as well as any object accessed within an instrumented method. Making this available on demand from within the console as well as in the event of an error via automatic diagnostic snapshot dumps. Exceptions can be introduced via the ThrowAfter or ThrowBefore aspect extension, with the Diagnostic extension adding state to global, thread, and stack frames and the Dump extension decided on whether to dump the state when an exception is thrown by an instrumented method. The benefit in separating these concerns is that one can deploy each extension across different technology tiers. Framing State in JUnit & TestNG Tests http://blog.jinspired.com/?p=178 Note that the underlying open API and tooling is not tied to one particular instrumentation technology such as AspectJ. William
  3. JXInsight has had this feature implemented for sometime via its Diagnostics Open API and corresponding Dump, Diagnostic, Frame, and Throw(Before|After) aspect extensions.

    Our solution goes even further by recording comprehensive object state (min-heap dumps) associated with the target object, arguments, thread state as well as any object accessed within an instrumented method. Making this available on demand from within the console as well as in the event of an error via automatic diagnostic snapshot dumps.

    Exceptions can be introduced via the ThrowAfter or ThrowBefore aspect extension, with the Diagnostic extension adding state to global, thread, and stack frames and the Dump extension decided on whether to dump the state when an exception is thrown by an instrumented method. The benefit in separating these concerns is that one can deploy each extension across different technology tiers.

    Framing State in JUnit & TestNG Tests
    http://blog.jinspired.com/?p=178

    Note that the underlying open API and tooling is not tied to one particular instrumentation technology such as AspectJ.

    William
    I'm not familiar with JXINsight so could you tell me which feature(s) are you referring to? Does JXInsight allow the exceptions to be thrown based on stack trace analysis? I don't usually want to throw an exception every time method x is called, only when method x is called in the context of a particular call stack. For example, I don't want to throw a StaleObjectStateException every time my dao.update() method is called, only when it is called in the context of a particular call stack. Does JXINsight allow the injected exception to be selected at runtime from a simple dropdown with developer recommended likely exceptions highlighted? And without requiring the user to have network connectivity to the application being monitored? User and application are both clients of the Jexin web app so they never have to communicate directly. Does JXInsight support side-by-side stack trace comparisons to analyze the difference in call stacks for repeated executions of a test or to compare the path of the successful execution with the execution after an exception has been injected? Does JXInsight allow you to merge stack traces from separate threads and/or JVMs into a single trace? This is particularly useful in messaging type applications where you want to view the progress of a message from app-to-app. Its also very helpful when you are having concurrency issues. If you use web services this feature allows you to integrate the stack trace from a web service call into the caller to view/compare as a single unit. The AspectJ integration is limited to a single aspect added for convenience. There is no requirement to use it. The aspect just calls methods on the TraceServer which is just a POJO. You can even do away entirely with the Jexin library and create your own implementation of the protocol to the web app if you like. Finally, is JXInsight open source and free?
  4. I'm not familiar with JXInsight
    Exactly. Maybe you should become more familiar with the product before asking such questions then you might realize the scope, extensibility, and quality of JXInsight. It can merge, aggregate and trace (true tag and trace), diagnose, and meter across threads and processes - clustering data at various levels. DataGrid Traffic Analysis http://blog.jinspired.com/?p=58 Parallel & Remote Tracing http://blog.jinspired.com/?p=144 Here is a starting point: http://www.jinspired.com/products/jxinsight/index.html Generating exceptions is a tiny, tiny feature with our problem diagnostics solution that allows offline analysis of in-flight requests and transactions in a powerful UI console. To be honest I never blogged about this particular enhancement because I do not think developers or testers in general have sufficient knowledge of the underlying application execution model and contracts to make this useful in practice not the mention the lack of visualizations needs to effectively show differences in execution paths (paths != call stacks). I still have trouble convincing some developers of the importance of resource transaction analysis in the absence of exceptions (...rollbacks) William
  5. JXInsight is FREE for development usage.
  6. JXInsight is FREE for development usage.
    So as long as the development team is using it but not the QA team its free? Just wanted to clarify this. Is it also open source?

  7. I'm not familiar with JXInsight


    Exactly.

    Maybe you should become more familiar with the product before asking such questions then you might realize the scope, extensibility, and quality of JXInsight.
    A bit hostile aren't we? I certainly hope developers have knowledge of the underlying execution model of their own application (unless I misunderstand your statement). It may be lower level than QA should be required to understand but I think that depends on the particular environment. Jexin is based on a tool that was originally developed in-house for QA use (many thanks to that unnamed company). This is one reason Jexin allows developers to limit the methods included in traces; to try to simplify the traces. I'll be happy take a look at your site. If nothing else I'd love to know what "offline analysis of in-flight requests" means. I suppose I'll have to get the answers to my questions from there since you didn't really answer them very specifically here. I will be happy to answer any questions about Jexin even if they could be figured out by reading the documentation. I created the project because I found the tool useful and thought others might as well. If I get positive feedback that it's useful I'll continue to support and enhance it. I have a number of ideas. If the community doesn't find it useful I'll move on to other things.
  8. I'll be happy take a look at your site. If nothing else I'd love to know what "offline analysis of in-flight requests" means.
    Let me save you some energy. Offline: Not connected to a central management server. Our snapshots (in-memory database) can be exported and viewed by anyone using the console which by the way is free irrespective of usage. In-flight Request: At any moment in time (and not when an exception is artificially generated) you can take a diagnostic snapshot providing a comprehensive execution flow and object field state model of threads, diagnostics frames (method invocations) and associated diagnostic variables (target objects, thread locals, arguments, and other framed objects) related to requests being processed (in-flight? black box?). William
  9. no offense William, but you should cut the guy some slack. Not everyone can afford to purchase a tool and I'm sure there's room in the market for an open source one. In any event, I'll be checking it out for plain curiosity. Kudos James.
  10. Congrats on the release...[ Go to top ]

    Congrats on the release James, keep up the good work. William, pull your head in a bit mate.....
  11. I'll be checking it out for plain curiosity. Kudos James.
    Thanks Jin. Feel free to post here or send me an email with any feedback you have on the functionality, documentation, or whatever. My main goal at the moment is to make the project as useful and easy to work with as possible.
  12. Thanks for taking the time to put this into the open source arena. I think it provides an especially simple mechanism to ensure my code responds as expected to exceptions that are a pain to generate in practice. The Merge Traces display also strikes me as a useful visualization tool. One question: Are templates able to be persisted or is that a potential future enhancement? Thanks again... Brett
  13. Hi Brett, leaving aside the product/projects and how anyone would effectively decide were to inject artificial exceptions that would could possibly occur in practice can you explain how you would go about ensuring your code responds as expected? Would this "ensure" be that the exception is caught at the appropriate layer? Reported to the user? Logged in the some file? Would this also cover resource transactions and if so how would you effectively determine that the outcome (rollback? restore savepoint) was performed appropriately? But what about the real nasty and more so common bugs caused by our memory access (read/updates) not being transactional leading to system/component/request state infections? By the way in my experience a significant amount of exceptions thrown in enterprise applications are as a result of a state infection caused a previously executed request (that never threw an exception). You might like to read the first two paragraphs in the following entry. What state does that Object have and hold? http://blog.jinspired.com/?p=176 William
  14. Hi Brett, leaving aside the product/projects and how anyone would effectively decide were to inject artificial exceptions that would could possibly occur in practice can you explain how you would go about ensuring your code responds as expected?
    William: For example, there are several areas in the codebase I work on where I may want to handle an internal RuntimeException called a Fault. I could engineer my test environment to make those occur (although that can be time consuming in certain cases); however, it seems like it would be significantly easier to hook up Jexin, inject the Fault where I want it to occur, and confirm in detail that the Fault was handled where and how I intended. The confirmation technique used is situation dependent (sometimes evidence is in the log, other times it's in the GUI, and still other times I may choose to step through the code).
    Would this "ensure" be that the exception is caught at the appropriate layer?
    While functionally testing my code, this technique would increase my confidence level that the particular use-case I'm testing is handled as intended. Just as important, Jexin seems lightweight so it wouldn't take much time to go through the mechanics (even on an ad-hoc basis).
    But what about the real nasty and more so common bugs caused by our memory access (read/updates) not being transactional leading to system/component/request state infections? By the way in my experience a significant amount of exceptions thrown in enterprise applications are as a result of a state infection caused a previously executed request (that never threw an exception).
    I completely agree, but I don't necessarily see Jexin as attempting to address these more complex root cause analysis issues (at least at this time). Brett
  15. Are templates able to be persisted or is that a potential future enhancement?

    Thanks again...
    Brett
    Hey Brett, thanks for taking the time to check out Jexin. Templates are not currently persistent. If you bounce the servlet container they are gone. If people start using Jexin I'll start adding enhancements and that is near the top of the list. I'm debating whether they should be persisted in a DB or on the file system. The DB provides more flexibility but then installation becomes more of a pain than just dropping in a war file. I want to keep Jexin as easy to adopt as possible. Any thoughts? A bit of background for readers: Jexin works in a record/replay paradigm. First you record a stack trace. Next you edit the trace to inject an exception at some point. Now its a template. Jexin compares the stack traces of running threads with the templates and if it finds a match at the point a template is configured to inject an exception then the exception is thrown. That's a pretty high level view but it should give folks an idea what we are talking about. Thanks for the question and feel free to ask more.
  16. I think supporting the injection of checked exceptions would be a useful near-term enhancement. In many cases I'd like to ad-hoc inject network-oriented subclasses of IOException (mainly because they are a pain to create in a test network). Might this be on the horizon? Thanks, Brett
  17. I think supporting the injection of checked exceptions would be a useful near-term enhancement.
    Thanks a lot for the input Brett. I agree totally. However, it is not a trivial feature. It will be the next feature I add and I'll do a release as soon as it is complete so it will be available to you.