After thinking about this more, I don't think that we should turn on
recovery at this point in the 3.0 release cycle. I think it is good
turning it on in trunk (3.1) so we can get lots of testing in before
releasing it.
One other thing, the tx logs should be in a directory in the data
directory. I'm not sure if that is happening now but the property
should be something like data/txlog.
-dain
On Mar 16, 2008, at 10:03 AM, Dain Sundstrom wrote:
On Mar 16, 2008, at 9:33 AM, David Jencks wrote:
On Mar 15, 2008, at 2:37 PM, David Blevins wrote:
On Mar 15, 2008, at 12:06 AM, David Jencks wrote:
While not ideal, I think using a working although slower
transport is a reasonable compromise to a faster, broken
transport until we can get a fixed activemq out.
We definitely need the vm transport for the embedded testing
scenarios and we don't have tx recovery yet, so this is something
we probably don't want enable by default. We can wrap the
wrapping with the "duct tape" flag like so:
if (System.getProperty("duct tape") != null) {
xaResource = new WrapperNamedXAResource(xaResource,
container.getContainerID().toString());
}
EndpointHandler endpointHandler = new EndpointHandler(container,
deploymentInfo, instanceFactory, xaResource);
If you have time to make the change and rollback the service-
jar.xml settings, that'd be great, otherwise I'll get to it before
we release.
You should probably check my work :-) but after some work I think
the current status is:
- recovery works if howl log configured in tm configuration
- there's a flag TxRecovery for MDB container and the DBCP pools
that turns on the NamedXAResource wrapping
- recovery and wrapping is turned on for standalone and tomcat, and
these use the amq tcp transport
- recovery and wrapping is turned off for embedded and it uses vm
transport
The tests break if you turn on recovery and wrapping in embedded
because the howl log locks its log files and does not unlock them.
Without a "stop" lifecycle call I don't know how the howl log can
determine its time for a clean shutdown.
How about a finalizer (assuming we have a point where the log is
GCed)? We could subclass the howl log service in OpenEJB and add
the finalizer.
-dain
