I looked at the HOWL project at ObjectWeb and seems that it is an old
project and no further development is made, so why we use it ?
On Sun, Mar 16, 2008 at 8:07 PM, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> 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
>
>
--
Thanks
- Mohammad Nour
