fidzu : JBoss

The single lock owner is a highly requested Infinispan improvement. The basic idea behind it is that, when writing to a key, locks are no longer acquired on all the nodes that own that key, but only on a single designated node (named "main owner").

How does it help me?

Short version : if you use transactions that concurrently write to the same keys, this improvement significantly increases your system' throughput.

Long version : If you're using Infinispan with transactions that modify the same key(s) concurrently then you can easily end up in a deadlock. A deadlock can also occur if two transaction modify the same key at the same time - which is both inefficient and counter-intuitive. Such a deadlock means that at one transaction(or both) eventually rollback but also the lock on the key is held for the duration of a lockAquistionTimout config option (defaults to 10 seconds). These deadlocks reduces the throughput significantly as transactions threads are held inactive during deadlock time. On top of that, other transactions that want to operate on that key are also delayed, potentially resulting in a cascade effect.

What's the added performance penalty?

The only encountered performance penalty is during cluster topology changes. At that point the cluster needs to perform some additional computation (no RPC involved) to fail-over the acquired locks from previous to new owners.
Another noticeable aspect is that locks are now being released asynchronously, after the transaction commits. This doesn't add any burden to the transaction duration, but it means that locks are being held slightly longer. That's not something to be concerned about if you're not using transactions that compete for same locks though.
We plan to benchmark this feature using Radargun benchmark tool - we'll report back!

Want to know more?

You can read the single lock owner design wiki or/and follow the JIRA JIRA discussions.

09 Nov 2011 8:57pm GMT

The latest beta in the Infinispan 5.1 "Brahma" series is out. So, what's in Infinispan 5.1.0.BETA4? Here are the highlights:

• A hugely important lock acquisition improvement has been implemented that results in locks being acquired in only a single node in the cluster. This means that deadlocks as a result of multiple nodes updating the same key are no longer possible. Concurrent updates on a single key will now be queued in the node that 'owns' that key. For more info, please check the design wiki and keep an eye on this blog because Mircea Markus, who's the author of this enhancement, will be explaining it in more detail very shortly. Please note that you don't need to make any configuration or code changes to take advantage of this improvement.
• 
  
• A bunch of classes and interfaces in the core/ module have been migrated to an api/ and commons/ module in order to reduce the size of the dependencies that the Hot Rod Java client had. As a result, there's been a change in the hierarchy of Cache and CacheContainer classes, with the introduction of BasicCache and BasicCacheContainer , which are parent classes of existing Cache and CacheContainer classes respectively. What's important is that Hot Rod clients must now code againts BasicCache and BasicCacheContainers rather than Cache and CacheContainer. So previous code that was written like this will no longer compile:

  import org.infinispan.Cache;
  import org.infinispan.manager.CacheContainer;
  import org.infinispan.client.hotrod.RemoteCacheManager;
  ...
  CacheContainer cacheContainer = new RemoteCacheManager();
  Cache cache = cacheContainer.getCache();
  

  Instead, if Hot Rod clients want to continue using interfaces higher up the hierarchy from the remote cache/container classes, they'll have to write:

  import org.infinispan.BasicCache;
  import org.infinispan.manager.BasicCacheContainer;
  import org.infinispan.client.hotrod.RemoteCacheManager;
  ...
  BasicCacheContainer cacheContainer = new RemoteCacheManager();
  BasicCache cache = cacheContainer.getCache();
  

  Previous code that interacted against the RemoteCache and RemoteCacheManager should work as it used to:

  import org.infinispan.client.hotrod.RemoteCache;
  import org.infinispan.client.hotrod.RemoteCacheManager;
  ...
  RemoteCacheManager cacheContainer = new RemoteCacheManager();
  RemoteCache cache = cacheContainer.getCache();
  

  We apologise for any inconvenience caused, but we think that the Hot Rod clients will hugely benefit from this vastly reducing the number of dependencies they need.
• 
  
• Finally, a few words about the ZIP distribution file. In BETA4 we've added some cache store implementations that were missing from previous releases, such as the RemoteCacheStore that talks to Hot Rod servers , and we've added a brand new demo application that implements a near-caching pattern using JMS. Please be aware that this demo is just a simple prototype of how near caches could be built using Infinispan and HornetQ.

As always, please keep the feedback coming. You can download the release from here and you get further details on the issues addressed in the changelog .

Cheers,
Galder

09 Nov 2011 5:57pm GMT

The RichFaces 4.1 Milestone 4 release is now available for download! With this M4 release we focused on stabilizing the features we introduced in the earlier 4.1 release-train milestones (M1, M2, M3). The release following M4 will be our 4.1 release candidate, so we want to make sure we achieve maximum stability with M4. Some of the key areas we touched are listed below.

If your keen and want to get started right away, you can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to 4.1.0.20111101-M4. For more information on setting up a RichFaces 4 application, refer to our getting started guide.

Mobile showcase improvements
The CSS 3 overlay was improved to provide better mobile compatibility of the components. We also added an ajax status indicator to the mobile showcase. Since it is entirely an ajax driven application, the status indicator improves the user experience dramatically.

Resource mapping
The resource mapping feature introduced in M3 has been made more usable, adopting a consistent naming convention, with reasonable defaults. Additionally the ability to completely disable the feature was introduced, should you want to handle resources yourself in your applications.

Client Side validation
Improvements to the client-side validation (CSV) involved better aligning the client-side regexp with the Bean Validation specification. The CSV mechanism for discerning component values on the client (using javascript) was enhanced to improve the CSV interop with other JSF component providers.

Individual component fixes
The file upload component has some new attributes, allowing for more fine-grained control over what the user is able to upload to the server. The pickList saw the switchByClick and switchByDblClick functionality from RichFaces 3 ported to RichFaces 4, further improving the RF 3 to RF 4 migration story.

Misc. Fixes
Some additional issues resolved include a jQuery update (to version 1.6.4), and improvements to both the simpleapp and GAE RichFaces archetypes. Many more fixes and improvements were checked, feel free to browse the issues fixed to see what else has been improved.


Forward: CR1 & Further Stabilisation
The CR1 development is currently ongoing, with a focus on providing documentation for all the new 4.1 features, and further stabilisation. So give M4 a spin, and let us know what you think! Drop a note in the forums, or join us for our weekly community/team meetings in IRC.

09 Nov 2011 5:35pm GMT

I'm happy to announce new Weld 1.1.3.Final release.

• Release notes

With this release we finally moved Weld Core Arquillian tests by default to JBoss AS7, making the build easier and faster -- thanks Stuart.

But this of course doesn't mean we forgot about other containers;

• it's still fully tested against latest GlassFish (thanks GF guys!),

• added new web container tests (Tomcat 7; thanks Matija) and

• reduced Jetty config a bit (thanks Geoffrey).

Other interesting issues or features include:

• simple portlet integration - thanks Marko

• better conversation handling - thanks Lincoln and George; btw, LB3 I expect more patches from now on ;-)

• resolution by name - thanks Martin

• Java like abstract method handling in decorators- thanks me; since I'm already thanking everyone :-)

Weld' github master will now be the basis of future 1.2 releases, moving current to branch 1.1.

(since there already is an abandoned 1.1 branch, we'll first move that one to 1.1-legacy)

I also have a few exciting announcements - in case you missed them:

• Weld-OSGi: Injecting easyness in OSGi is coming out soon as part of next Weld 1.2 release!

• Jozef Hartinger moved to Weld team to work on Weld 2.0 (CDI 1.1 impl)

Onward to Weld 1.2 and 2.0!!

p.s.: let us know if there are any new issues with the latest release ;-)

09 Nov 2011 2:37pm GMT

http://download.jboss.org/jbosstools/updates/development/indigo/

09 Nov 2011 9:46am GMT

08 Nov 2011 7:59pm GMT

Work is now complete for 5.4.0.beta1 to use jBPM Work Items in the guided decision table.



New Actions have been added to perform the following:-

• Call a Work Item. Parameters can be either literal values, or bound to a Fact or Fact Field.

• Set the value of a field on an existing Fact to the value of a Work Item result.

• Set the value of a field on a new Fact to the value of a Work Item result.

Significantly, to maximize the usefulness of using Work Items in actions, is the ability to define bindings for Fact field values. This allows Facts' fields to be passed to Work Items.

Bound fields can also be used in predicate and formula Condition definitions too; which opens a world of further possibility which up until now has been unavailable.



Work Item definitions can either be defined as assets in Guvnor or included in a workitem-definitions.xml the format of which follows the normal jBPM Work Item definition.

A short video here demonstrates using Work Items in a decision table and a short example of how the feature can be leveraged from a Java application.

Unrelated to Work Items, but a welcome addition, is the ability to define an action to retract Facts.

06 Nov 2011 9:13pm GMT

Remember the Gif submarine patent from Unisys?
http://www.gnu.org/philosophy/gif.html
It's a classic story of why OSS and standards in general do not mix with patents.

While at business rules forum this year I was asked by Larry Goldberg, one of The Decision Model (TDM) authors what our plans were for Drools and TDM. You can read more about what TDM is here:
http://www.kpiusa.com/index.php?option=com_content&view=article&id=22&Itemid=8

While discussing future ways we could work together I asked them what their business model was. After discussing consulting and training I asked if there was a scalable business model, thinking maybe certification centres around the TDM brand. He answered IP. I asked what IP, for I was not aware of any software they had, he answered TDM is patented......... Say what now?

Yes I was kinda stunned by that too. I replied I couldn't discuss TDM any further or look at software that implemented it, without Red Hat legal guidance. This field is covered extensively in research, I don't believe they have anything that for instance isn't already covered by the god father of decision tables at Leuven University, Jan Vanthienen.
http://www.econ.kuleuven.be/prologa/

Mr Goldberg seemed confused by this, offering that everyone has to deal with patents when using software. Obviously someone who has not got the Red Hat message. So for those that don't know, let me spell it out :)


Open Source and Patents do not mix. When you get software from Red Hat you are guaranteed its 100% Open Source, not maybe OS or partly OS. From top to bottom, inside and out 100% OS goodness. But it doesn't stop there Red Hat guarantees and indemnifies it's customers that the software is not IP encumbered in any way. Those are cast iron assurance built universally into the Red Hat brand, and it's why Red Hat is the world's number one OSS company.

So you can imagine that making available the patent encumbered TDM as part of Drools does not fit with the above assurances and does not and will not happen.

For those vendors, OSS or not, make sure you are aware of this and have agreed licensing deals before walking into this IP trap and getting gauged later.

I hope that the TDM people might consider giving universal and perpetual access to their patent to allow wider adoption. I believe Red Hat has a patent pool they can donate too, if they need help in how to do this.

I would add that I have simplified things here. For instance various Open Source efforts are under way for defensive patents, to protect OSS, http://en.swpat.org/wiki/Defensive_patent_pools . Also some OSS licenses, like Apache allow patents but give universal access, while retaining the rights to act defensively. We have patent applications in the Drools team For this reason. You can read more about the Red Hat patent promise here:
http://www.redhat.com/legal/patent_policy.html

05 Nov 2011 10:27pm GMT

03 Nov 2011 10:42pm GMT

Fresh back from JUDCon 2011:London, I quickly want to blog about my Hibernate OGM presentation. For the impatient, all the code and the presentation itself is available on GitHub - ogm-kitchensink. The README.md gets you started with building, testing and deploying the code. Deployment is possible into a local JBoss AS 7 instance as well as into OpenShift Express.

The demo is based on the AS 7 quickstart application kitchensink and shows a registration screen with name, email and phone number. Even though this is a very simple application there are several interesting things going on under the hood, most importantly the use of OGM :-)

AS 7 modules

The demo uses OGM in the version 3.0.0.Alpha2 which requires Hibernate Core 3.6. However, AS 7 ships with Hibernate 4. The solution to this problem is to define a Hibernate 3 module as described by Scott in Using a different persistence provider with AS 7.0.1 . The demo does exactly that. In fact it actually bundles all the steps described in the blog and let you create the required modules via a single maven command. Just check out ogm-kitchensink, make sure your JBOSS_HOME variable is set properly and run:

mvn groovy:execute

This will copy all required module jars and configuration files into the appropriate location of your local AS 7 instance.

Running the demo locally

Provided you have installed the modules and started JBoss AS, you can run the demo locally as simple as:

mvn clean package jboss-as:deploy

Arquillian

Of course the demo comes with a test. Check out MemberRegistrationTest to see how to put together a Arquillian test and then run the test either via:

$ mvn test 

or

$ mvn test -DremoteTests=true

Check the profile setup in pom.xml to see the difference in the configuration.

OpenShift Express

Last but not least, let's push the demo into OpenShift Express. This is as simple as signing up for OpenShift, installing the rhc command line tools and then running:

 $ rhc-create-domain -n <domain>
 $ rhc-create-app -a <app> -t jbossas-7.0 --nogit
...
Success!  Your application is now published here:

      http://<name>-<domain>.rhcloud.com/

The remote repository is located here:

    <repo-url>
...
 $ git remote add openshift <repo-url>
 $ git push -f openshift master

The interesting bit here is to get the required modules installed on the server side. It turns out, all you have to do is to check add them to the git repository under .openshift/modules.

Again, check out README.md, script.md and the presentation slides for more information.

Looking forward to some feedback,

Hardy

03 Nov 2011 5:05pm GMT