Help

Jesper Pedersen leads the Java Connector Architecture (JCA) project within JBoss, a division of Red Hat. He also leads the projects JBoss Tattletale which focus on software quality, Papaki - an annotation scanner and JBoss Profiler 2 - an open source profiler suite.

Location: Westford, MA
Occupation: Principal Software Engineer
Archive
14. May 2013, 19:19 CET, by Jesper Pedersen

I'm happy to announce the release of IronJacamar 1.1.0.Beta5.

Full release notes are here.

Security inflow

We have finished up our security inflow model for our WorkManager, which allows you to configure mapping of users and groups in the Enterprise Information System domain to the domain used in the application server.

If you have additional use-cases that isn't covered by the existing configuration schemas let us know.

Improvements, improvements, and more improvements

This release really aims to finish up the work left on IronJacamar 1.1, so you will see a lot of small / bigger improvements in most of our components, like

And a ton of bug fixes. So, all in all, a release that should make you say Yummi !.

The Road Ahead

We aim to submit this release for inclusion in WildFly, and we further hope that this will be the last Beta release in the 1.1 series. So now is the time people if you are looking for something in the Java EE Connector Architecture space !

For Those About to Rock, We Salute You !

[WebSite] [Download] [Documentation] [JIRA] [Forum]

28. Feb 2013, 17:13 CET, by Jesper Pedersen

I'm happy to announce the release of IronJacamar 1.1.0.Beta4 - the first release of IronJacamar that targets the upcoming Java EE Connector Architecture 1.7 specification scheduled for inclusion in the Java EE 7 platform specification.

Full release notes are here.

Pool on steroids

We spent a lot time in this release going over our pool implementation, which of course controls all the physical connections to the Enterprise Information Systems such as databases.

Capacity policies

First off we added support for capacity policies. So what is a capacity policy, and why is it important. Capacity policies are divided into two categories: incrementers and decrementers.

An incrementer capacity policy specifies the properties when a new physical connection should be added to the pool, such as

  • MaxPoolSize -- increase to max-pool-size
  • Size -- increase by a certain size
  • Watermark -- increase until a certain size is reached

The incrementer policy will allow you to control how many or a specific size of the pool that is created when a connection isn't available for immediate check out. The default policy will remain the Size policy with a value of 1.

A decrementer capacity policy specifies the properties when the pool is scheduled for idle timeout cleanup, such as

  • MinPoolSize -- remove connections until min-pool-size is reached
  • Size -- remove a certain number of connections
  • TimedOut -- remove all connections that are registered with the timed out flag
  • Watermark -- remove connections until a certain size is reached

The decrementer policy will allow you to optimize the resources used in a pool each time idle timeout is scheduled. The default policy will remain the TimedOut policy.

You can read more about the capacity policies here.

Flush strategies

Next we looked at our flush strategies, which specifies which connections that are removed in case of an error on a connection. This led to

  • FailingConnectionOnly (default)
  • InvalidIdleConnections (new - will remove invalid idle connections)
  • IdleConnections
  • Gracefully (new - will remove all idle connections, and mark checked out connections for destruction upon return)
  • EntirePool

and their related strategy which works on all sub-pools across credentials. This allow much finer control of the pool in error situations.

Statistics

We added some new metrics to our statistics too

  • AverageGetTime
  • MaxGetTime
  • TotalGetTime
  • InUse
  • BlockingFailureCount
  • WaitCount

to give a more detailed view of the run-time behaviour of pool.

Initial size

Last we added support for specifying the initial size of the pool upon start up.

Hopefully you find all these changes just as exciting as us !

DistributedWorkManager

The DistributedWorkManager implementation also got an update, and both the Socket and JGroups transports are now considered ready for general testing, so give them a spin.

In order to help creating a cluster of IronJacmar instances we added some Apache Ant tasks, and Apache Maven mojos to control IronJacamar instances. Our test suite features test cases for both transports, so you can get an idea of how a cluster is created by looking there.

Java EE Connector Architecture 1.7

As stated above, this release targets the upcoming Java EE Connector Architecture 1.7 specification which will be included in the Java Enterprise Edition 7 platform specification.

The specification adds some new feature, but remains backwards compatible with the previous releases of the specification. I'll discuss these new features once the specification have received the final approval.

So hopefully soon you will see this release featured in the upcoming JBoss Application Server 8.0 release.

Other changes

There were other changes in this release

  • Initial support for converting a weblogic-ra.xml resource into an IronJacamar one
  • Numerous component updates in order to align against our EE 7 implementation
  • Bucket of bug fixes

The Road Ahead

A lot of changes (phew!) over the last 3 months to bring IronJacamar into a new league. But we are of course not stopping there - we still got more changes planned before we go into feature freeze for JCA 1.7 certification. So if you have a good idea now is the time to speak up in our forum !

For Those About to Rock, We Salute You !

[WebSite] [Download] [Documentation] [JIRA] [Forum]

28. Nov 2012, 16:46 CET, by Jesper Pedersen

I'm happy to announce the 3rd beta release of the IronJacamar 1.1 series.

The full release notes are here.

DistributedWorkManager

Our DistributedWorkManager implementation got a huge update in this release.

The distributed work manager is now unique per resource adapter activation - the same goes for the BootstrapContext. This means that these components acts like singletons, if multiple resource adapter activations uses the same configuration. This allows us to uniquely identify each instance within the JVM, and more importantly across the entire network, which allows us to optimize traffic and state between all the nodes in the cluster.

We now have a distributed statistics implementation across the network which will allow you see the status of all your Work instances in addition to the local statistics instance.

Since the WorkManager is now unique within the JVM we had to eliminate our InVM transport implementation. However, we have added Apache Ant and Apache Maven support for our standalone distribution in order to quickly start, stop, deploy, undeploy and ping local or remote instances of the IronJacamar container to ease testing and control of JCA clustering features.

We will continue to work on the implementation, and hope that we can consider the implementation stable in our next beta release. The JGroups transport have some caveats in this release, but give the Socket one a spin.

Arquillian

Our Arquillian support got an update as well. We now support the @ArquillianResource annotation in order to allow access to internally used resources, like the embedded instance, as well as the JNDI context.

However, since we have an increased focus on having IronJacamar running on a local machine as well as in a cluster we decided to split the Arquillian support in its own component to allow for multiple implementations (embedded and remote) in the future. This meant that we had to change the package name from 'org.jboss.jca.embedded.arquillian' to 'org.jboss.jca.arquillian.embedded'. Now, we can just wait for the mob with pitchforks...

Eclipse plugin and tooling

Our Eclipse plugin got a major update in this release, as did our general tooling for code generation.

The Eclipse plugin will now allow you to validate and deploy your resource adapters and their activation configuration to a local or remote IronJacamar instance.

Our code generator now allows you to integrate our EIS test server instance in your development environment easily, so you don't have to depend on having a full EIS installation.

You will be able to see it all in action this week at JUDCon/Beijing !

Other stuff

The usual bug fixes, and improvements in other area of the release, so all in all a good reason to upgrade your development environments.

Remember to switch to a JDK7 profile !

The road ahead

We still have a way to go for our 1.1 goals, but we are getting closer with each step. We are still aiming for certification once EE 7 is released.

For Those About to Rock, We Salute You !

[WebSite] [Download] [Documentation] [JIRA] [Forum]

06. Sep 2012, 18:02 CET, by Jesper Pedersen

I'm happy to announce the 2nd beta release of the IronJacamar 1.1 series.

The full release notes are here.

Developer productivity

In this release we took a hard look at how resource adapter development is done, and what it would take to be more productive. The previous releases of IronJacamar have featured an embedded environment, and various tools to help you get started. But more was needed in our view.

First we got rid of the requirement to have an on-disk representation of the IronJacamar deployment descriptors. So now you are able to deploy a ShrinkWrap/Descriptor instead for all these XSDs.

Next was the ability to test your resource adapter in error scenarios such that you are sure that it'll behave correctly. For this we integrated the Byteman tool in the embedded environment.

Then, the biggest problem in resource adapter development: Access to the Enterprise Information System (EIS). An EIS can be large installation, and in many cases it isn't really suited to run as part of a developer test suite run, since they don't really integrate well with embedded unit testing. So we have included an EIS test server in our distribution where you can implement a Handler interface that mocks the communication protocol of the EIS in order to make your smoke tests pass without an actual EIS installation. The EIS test server can run in Apache Ant, Apache Maven and standalone environments, so you should be covered in most cases. Otherwise let us know. Our code generator of course knows how to handle the integration, so you can check it out that way. And I'm not saying that using the EIS test server is enough for your resource adapter to go into a real test or production environment; it is a help for resource adapter developers, not a golden bullet.

Finally we upgraded the libraries used for our embedded platform in order to get the latest fixes.

You can find more information here:

And our Eclipse plugin have been verified on Eclipse 4.2 (Juno) to top it off :)

DistributedWorkManager on steroids

The DistributedWorkManager saw a big update in this release.

Our policy module was updated with a WaterMark implementation, which will look at how many free threads are available to the local WorkManager. The default setup is a value of 0, which will start to distribute Work instances once there are no free threads locally.

Our selector module got a MaxFreeThreads implementation, which will select the DistributedWorkManager in the cluster with the most free threads available for execution.

The real kicker was the addition of a JGroups based transport, which will allow you to configure the cluster parameters in much more detail taking IronJacamar into NFL. No more college football here.

Now that we have all the core modules, we will focus on implementation details that will tackle more advanced scenarios of distribution and thread management.

And the core WorkManager implementation also saw numerous fixes to align it more against the specification text.

Other improvements

There were other improvements in this release:

  • Updates to our validator tool
  • Major updates to our resource adapter information tool
  • Updates to the JDBC resource adapter, especially in the reauth area
  • Added support for deploying to a remote IronJacamar installation

Good stuff.

The Road Ahead

In short - it is full speed ahead !! We now got THE best platform for resource adapter development - prove us wrong ! This will enable us to get our new features tested and verify your reports about potential bugs at a quicker speed.

With EE7 getting closer we will focus in a higher degree on getting IronJacamar 1.1 ready for certification, and making sure that all of the specification is covered.

IronJacamar 1.1.0.Beta2 will be our last release on Java SE 6 - the time has come to move to Java SE 7.

For Those About to Rock, We Salute You !

[WebSite [Download] [Documentation] [JIRA] [Forum]

15. Jun 2012, 15:46 CET, by Jesper Pedersen

I'm very happy to announce the first beta of the IronJacamar 1.1 series ! This is a major milestone for us, since this release adds support for the optional features of the Java EE Connector Architecture 1.6 specification.

Full release notes are here.

Lazy connection manager

This release finishes our work on our lazy connection manager implementation. We covered the association part in an earlier blog which leaves the enlistment part.

Lazy enlistment allows the resource adapter to control when the ManagedConnection is enlisted in the transaction associated with the invocation. This has the benefit of not having the enlistment overhead if the connection never needs to be enlisted.

So for resource adapters that supports read-only scenarios you will see a nice performance improvement.

Distributed work manager

This release features our initial distributed work manager, which allows javax.resource.spi.work.DistributableWork instances to be reschedule for execution in another work manager instance to which it was submitted.

The distributed work manager is basically a standard work manager with three additional components

  • Policy
  • Selector
  • Transport

The Policy decides when a DistributableWork instance should be executed in another work manager. We currently support

  • Never -- never distribute to another work manager
  • Always -- always distribute to another work manager

More policies are on their way.

The Selector decides which work manager that should receive the DistributableWork instance. We currently support

  • FirstAvailable -- pick the first work manager in the list that is available
  • PingTime -- pick the work manager which has the lowest ping time

Future releases will include more selectors.

The Transport handles the actual transport of the DistributableWork instance. We have included support for the following transports

  • InVM -- communication between work managers in the same JVM
  • Socket -- communication between work managers using standard Java sockets

in this release. We will include support for additional transports in future releases.

We have added a org.jboss.jca.core.api.workmanager.DistributableContext class which will allow you to define overrides to control the execution.

If you thought to yourself Did IronJacamar just get support for clustering ? - the answer would be yes !

Eclipse plugin

We now have a plugin for the Eclipse development environment, which provides an Eclipse integration for our code generator such that you don't have to use the command line to generate the project skeleton for your resource adapter.

We will of course integrate our other tools, such as the validator, into the plugin in future releases.

The Road Ahead

This is the first beta release of IronJacamar 1.1 which means we are getting closer a stable release, but there is still a lot of work that needs to be done. But that is what Beta's are for :) And don't forget your own ideas for the project, keep the feedback coming !

Looking forward to meeting you all at JUDCon !

For Those About to Rock, We Salute You !

[WebSite] [Download] [Documentation] [JIRA] [Forum]

Showing 1 to 5 of 57 blog entries