Consider following trivial JavaEE application:
We want to test FooBean. However FooBean uses database or a distributed cache (e.g. Infinispan) or even another EJB bean. I.e. it depends on expensive component.
execution goes straight without locking anything in database. Execution may fail if a concurrent thread modified the same record ( OptimisticLockingException will be throw in this case)
database-level locks are acquired and hence deadlock may occur
|Transaction Span||Temporal and spatial span
entity version could be conveyed to client which can hold it as long as he wants. This allow a virtual transaction to span both temporal and spatial. Only during commit version check will be enrolled to ensure data integrity
it would be a suicide to hold a database-level lock on an entity which is edited by client remotely. This would quickly exhaust all system resources. As such no transaction span is available
changes made to an entity in another thread are detected and transaction is aborted – this prevents unwanted overwrites
changes made to an entity in another thread are not detected – they are simply overwritten (last change wins)
|Changes in Tables||Required
need to add column into each table for storing a version counter ( javax.persistence.Version)
everything needed is provided by database itself
doesn’t require and database interactions – recommended for web apps which must scale
requires explicit locking in database which is expensive
Let’s consider a JavaEE web application with an API exposed via RESTful endpoints. Exceptions… They are just everywhere and of course they will be raised in our API as well. As such during development of API following challenges will emerge:
While working on this release it became clear that object’s dumping must be more smart and tunable – otherwise there is lots of noise when metracer encounters complex system objects. This would be addressed in a next metracer release.
Have fun and glad to see your feedback!
I’m happy to announce a new 1.3.7 release of metracer. Comparing to previously announced 1.3.3 released there were many significant changes including:
Say you’re writing a Java console application and want to handle user input in an unbuffered mode. That’s said you don’t want the user to press Enter / Return after some typing – you want that every keyboard hit is delivered to your program immediately. Something similar is implemented in metracer for closing the program when user presses ‘q’. Let’s see how to implement this in Linux.
|1||Dynamic instrumentation||Now it’s possible to inject tracing into a running Java process without any restarts! One can repeat this many times for different classes and methods. After one is finished with experiments all instrumentation traces can be removed leaving application in an original state.
To ease metracer.jar launching a frontend script – metracer.sh – was introduced. One only needs this single script (without any additional bits) to start working! There are a built-in usage notice and help message for a quick on-boarding.
Such dynamic instrumentation was made possible by the use of Java Attach API and JMX technologies
|2||No more promiscuous patching of ClassLoader||Such patching was introduced as an aid against isolation imposed by JavaEE app servers (e.g. WildFly).
It was found another more elegant way to workaround this based on the fact that metracer bits are loaded into a system ClassLoader (see here). Given this one could easily resolve reference to a com.develorium.metracer.Runtime class from any point of program via code:
By using the code snippet above one doesn’t need anymore to patch any class loaders!
|3||Improved stability of instrumentation||Several design flaws and bugs in an instrumentation code were identified and fixed which lead to
With these changes metracer is now a fully functional developer tool ready for hard use in production! Enjoy the POWER of METRACER!
New version of metracer 1.2.0 was just released. Main changes are:
|1||Use of ASM for instrumentation|| A move was made towards ASM instrumentation framework instead of Javassist. This allowed to:
|2||Reporting of return values||Now there is information of return values of instrumented methods, e.g.:|
|3||Extended reporting of exceptions||Now the string representation of exception is printed for instrumented methods, e.g.:|
With these changes metracer became more efficient, lightweight. Changes provide an opportunity for “hot” code instrumentation (without program restart).