[Carbonado-interest] com.amazon.carbonado.repo.sleepycat.BDBRepository has hard-coded setAutoShutdownEnabled(true);

Discussion:

Dan Washusen

2008-05-20 00:34:40 UTC

Hi All,
I'm just working through an issue regarding error while shutting down our
application. I've noticed that despite my code explicitly turning off the
'autoShutdownEnabled' feature via the ShutdownCapability class, the
repository still automatically shuts down.

I've started digging through the carbonado code and noticed that start
method in the com.amazon.carbonado.repo.sleepycat.BDBRepository class is

464 void start(long checkpointInterval, long deadlockDetectorInterval) {
465 getLog().info("Opening repository \"" + getName() + '"');
466
467 if (mRunCheckpointer && checkpointInterval > 0) {
468 mCheckpointer = new Checkpointer(this, checkpointInterval);
469 mCheckpointer.start();
470 } else {
471 mCheckpointer = null;
472 }
473
474 if (mRunDeadlockDetector && deadlockDetectorInterval > 0) {
475 mDeadlockDetector = new DeadlockDetector(this, deadlockDetectorInterval);
476 mDeadlockDetector.start();
477 } else {
478 mDeadlockDetector = null;
479 }
480
481 *setAutoShutdownEnabled(true);*
482 }
Am I on the right track?

Cheers,
Dan

Dan Washusen

2008-05-20 06:56:18 UTC

Permalink

OK, so basically what I need is the ability to configure the addition of a
auto shutdown hook in the repository builder. I think this can be achieved
by making the following changes:

1. In the BDBRepositoryBuilder class add a 'autoShutdownEnabled' boolean
property which defaults to true.
2. In the constructor of the BDBRepository class call the
'setAutoShutdownEnabled(boolean)' method with the value of the
'autoShutdownEnabled' property from the builder.
3. In the 'start(long, long)' method of the BDBRepository class remove
the 'setAutoShutdownEnabled(true)' call.

Cheers,
Dan

Post by Dan Washusen
Hi All,
I'm just working through an issue regarding error while shutting down our
application. I've noticed that despite my code explicitly turning off the
'autoShutdownEnabled' feature via the ShutdownCapability class, the
repository still automatically shuts down.
I've started digging through the carbonado code and noticed that start
method in the com.amazon.carbonado.repo.sleepycat.BDBRepository class is

Cheers,
Dan

Brian S O'Neill

2008-05-20 13:39:27 UTC

Permalink

Turning off the shutdown hook from the shutdown capability should work.
I'm surprised that it is not working for you. If you want to integrate
your own shutdown hook, they can be added to the BDBRepositoryBuilder
via the setPreShutdownHook and setShutdownHook methods.

I'll experiment a bit and report back.

Post by Dan Washusen
OK, so basically what I need is the ability to configure the addition
of a auto shutdown hook in the repository builder. I think this can
1. In the BDBRepositoryBuilder class add a 'autoShutdownEnabled'
boolean property which defaults to true.
2. In the constructor of the BDBRepository class call the
'setAutoShutdownEnabled(boolean)' method with the value of the
'autoShutdownEnabled' property from the builder.
3. In the 'start(long, long)' method of the BDBRepository class
remove the 'setAutoShutdownEnabled(true)' call.
Cheers,
Dan
Hi All,
I'm just working through an issue regarding error while shutting
down our application. I've noticed that despite my code
explicitly turning off the 'autoShutdownEnabled' feature via the
ShutdownCapability class, the repository still automatically shuts
down.
I've started digging through the carbonado code and noticed that
start method in the
com.amazon.carbonado.repo.sleepycat.BDBRepository class is
464 void start(long checkpointInterval, long deadlockDetectorInterval) {
465 getLog().info("Opening repository \"" + getName() + '"');
466
467 if (mRunCheckpointer && checkpointInterval > 0) {
468 mCheckpointer = new Checkpointer(this, checkpointInterval);
469 mCheckpointer.start();
470 } else {
471 mCheckpointer = null;
472 }
473
474 if (mRunDeadlockDetector && deadlockDetectorInterval > 0) {
475 mDeadlockDetector = new DeadlockDetector(this, deadlockDetectorInterval);
476 mDeadlockDetector.start();
477 } else {
478 mDeadlockDetector = null;
479 }
480
481 *setAutoShutdownEnabled(true);*
482 }
Am I on the right track?
Cheers,
Dan
------------------------------------------------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
------------------------------------------------------------------------
_______________________________________________
Carbonado-interest mailing list
https://lists.sourceforge.net/lists/listinfo/carbonado-interest

Brian S O'Neill

2008-05-20 14:01:50 UTC

Permalink

It played around a bit with disabling the auto shutdown hook and it
appeared to work fine. I just added this line (skipping the null check):

repository.getCapability(ShutdownCapability.class).setAutoShutdownEnabled(false);

Post by Brian S O'Neill
Turning off the shutdown hook from the shutdown capability should
work. I'm surprised that it is not working for you. If you want to
integrate your own shutdown hook, they can be added to the
BDBRepositoryBuilder via the setPreShutdownHook and setShutdownHook
methods.
I'll experiment a bit and report back.

Dan Washusen

2008-05-20 22:17:19 UTC

Permalink

Hi Brain,
Thanks for looking into it...

I'm attempting to use the repository builder at the end of a long running
quartz job. Quartz has been configured to not allow shutdown until any
running jobs have completed. So the basic flow is;

1. Quartz triggers the long running job.
2. A shutdown signal is sent to the application.
3. The long running quartz job finishes it's main task and uses the
repository builder to build the repository.
1. As a result of the hard-coded 'setAutoShutdownEnabled(true)' the
'BDBRepository$ShutdownHook' is fired and the repository I'm
attempting to
use to closes.
4. I call
'repository.getCapability(ShutdownCapability.class).setAutoShutdownEnabled(false);'
with no affect.
5. My long running quartz job attempts to use the repository and gets a
'Attempt to use a non-open environment' exception.
6. Due to an issue in quartz (I think) the exception causes quartz to go
into a tail-spin.

So, I'm pretty sure the culprit the the hard-coded
''setAutoShutdownEnabled(true)' in the BDBRepository start method...

Cheers,
Dan

Post by Brian S O'Neill
It played around a bit with disabling the auto shutdown hook and it
repository.getCapability(ShutdownCapability.class).setAutoShutdownEnabled(false);

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Carbonado-interest mailing list
https://lists.sourceforge.net/lists/listinfo/carbonado-interest

Brian S O'Neill

2008-05-21 02:17:43 UTC

Permalink

I think I understand now. You're building the repository while a
shutdown is in progress, in which case you don't have an opportunity to
turn off the shutdown logic. The default behavior is to shutdown the
repository, and if a shutdown is in progress, it does this immediately.

Post by Dan Washusen
Hi Brain,
Thanks for looking into it...
I'm attempting to use the repository builder at the end of a long
running quartz job. Quartz has been configured to not allow shutdown
until any running jobs have completed. So the basic flow is;
1. Quartz triggers the long running job.
2. A shutdown signal is sent to the application.
3. The long running quartz job finishes it's main task and uses the
repository builder to build the repository.
1. As a result of the hard-coded
'setAutoShutdownEnabled(true)' the
'BDBRepository$ShutdownHook' is fired and the repository
I'm attempting to use to closes.
4. I call
'repository.getCapability(ShutdownCapability.class).setAutoShutdownEnabled(false);'
with no affect.
5. My long running quartz job attempts to use the repository and
gets a 'Attempt to use a non-open environment' exception.
6. Due to an issue in quartz (I think) the exception causes quartz
to go into a tail-spin.
So, I'm pretty sure the culprit the the hard-coded
''setAutoShutdownEnabled(true)' in the BDBRepository start method...
Cheers,
Dan

Brian S O'Neill

2008-05-21 05:55:26 UTC

Permalink

Here's what I propose: change the contract for the shutdown capability
such that the IllegalStateException thrown by Runtime.addShutdownHook is
not caught. When the BDBRepository calls setAutoShutdownEnabled(true),
it catches the IllegalStateException and ignores it. This means that the
shutdown is not run if the repository is opened when the VM is shutting
down.

I don't think this is a significant change, since it is not common to
open a repository during shutdown. If the change is made to the mainline
branch, then it applies to the unreleased version 1.2, which is still
allowed to have some API changes.

That's correct...
I think I understand now. You're building the repository while a
shutdown is in progress, in which case you don't have an
opportunity to turn off the shutdown logic. The default behavior
is to shutdown the repository, and if a shutdown is in progress,
it does this immediately.
Hi Brain,
Thanks for looking into it...
I'm attempting to use the repository builder at the end of a
long running quartz job. Quartz has been configured to not
allow shutdown until any running jobs have completed. So the
basic flow is;
1. Quartz triggers the long running job.
2. A shutdown signal is sent to the application.
3. The long running quartz job finishes it's main task and uses the
repository builder to build the repository.
1. As a result of the hard-coded
'setAutoShutdownEnabled(true)' the
'BDBRepository$ShutdownHook' is fired and the repository
I'm attempting to use to closes.
4. I call
'repository.getCapability(ShutdownCapability.class).setAutoShutdownEnabled(false);'
with no affect.
5. My long running quartz job attempts to use the repository and
gets a 'Attempt to use a non-open environment' exception.
6. Due to an issue in quartz (I think) the exception causes quartz
to go into a tail-spin.
So, I'm pretty sure the culprit the the hard-coded
''setAutoShutdownEnabled(true)' in the BDBRepository start method...
Cheers,
Dan

Dan Washusen

2008-05-21 06:44:22 UTC

Permalink

I think it would be more obvious (for a user of carbonado) to have the
ability to explicitly control the addition of a shutdown before the
repository has been created, however I'd be more than happy with the changes
you mentioned below.

As this issue is corrupting jobs that take several hours to complete I'll
have to modify and re-package the carbonado code to work around it. If the
change you described below is the solution then I'll mirror those changes on
the 1.1.2 code in order to minimize the impact of upgrading the 1.2...

Cheers,
Dan

Here's what I propose: change the contract for the shutdown capability such
that the IllegalStateException thrown by Runtime.addShutdownHook is not
caught. When the BDBRepository calls setAutoShutdownEnabled(true), it
catches the IllegalStateException and ignores it. This means that the
shutdown is not run if the repository is opened when the VM is shutting
down.
I don't think this is a significant change, since it is not common to open
a repository during shutdown. If the change is made to the mainline branch,
then it applies to the unreleased version 1.2, which is still allowed to
have some API changes.

Dan Washusen

2008-05-21 06:45:48 UTC

Permalink

Oh, and thanks again for looking into my issue and for your great work on
Carbonado... :)

Post by Dan Washusen
I think it would be more obvious (for a user of carbonado) to have the
ability to explicitly control the addition of a shutdown before the
repository has been created, however I'd be more than happy with the changes
you mentioned below.
As this issue is corrupting jobs that take several hours to complete I'll
have to modify and re-package the carbonado code to work around it. If the
change you described below is the solution then I'll mirror those changes on
the 1.1.2 code in order to minimize the impact of upgrading the 1.2...
Cheers,
Dan

Post by Brian S O'Neill
Here's what I propose: change the contract for the shutdown capability
such that the IllegalStateException thrown by Runtime.addShutdownHook is not
caught. When the BDBRepository calls setAutoShutdownEnabled(true), it
catches the IllegalStateException and ignores it. This means that the
shutdown is not run if the repository is opened when the VM is shutting
down.
I don't think this is a significant change, since it is not common to open
a repository during shutdown. If the change is made to the mainline branch,
then it applies to the unreleased version 1.2, which is still allowed to
have some API changes.

Brian S O'Neill

2008-05-21 13:55:57 UTC

Permalink

I thought about following your suggestion of adding a method to the
builder and I found that it would have more of a ripple effect. Many
different repository types install a shutdown hook, and they all use the
ShutdownCapability to expose this. The replicated repository also uses
this optional capability in order to control shutdown of the master and
replica.

If the builder also supported controlling shutdown behavior, I feel it
would need to be added to the standard builder interface. All builders
would need to be retrofitted to implement this new method. Other options
include reflection, casting or inventing a builder capability.

Of course the builder shutdown option could simply be defined on the few
"core" repository builders like BDB and JDBC, but it would be somewhat
inconsistent. It would also mean that there are multiple ways of
controlling the same option.

Post by Dan Washusen
I think it would be more obvious (for a user of carbonado) to have the
ability to explicitly control the addition of a shutdown before the
repository has been created, however I'd be more than happy with the
changes you mentioned below.
As this issue is corrupting jobs that take several hours to complete
I'll have to modify and re-package the carbonado code to work around
it. If the change you described below is the solution then I'll
mirror those changes on the 1.1.2 code in order to minimize the impact
of upgrading the 1.2...
Cheers,
Dan

Dan Washusen

2008-05-22 00:41:31 UTC

Permalink

Yep, that sounds reasonable; I only really use a small part of carbonado so
my suggestion was probably a little selfish... :)

Do you have an issue number I can use to monitor the code changes you make?

Cheers,
Dan

Post by Brian S O'Neill
I thought about following your suggestion of adding a method to the
builder and I found that it would have more of a ripple effect. Many
different repository types install a shutdown hook, and they all use the
ShutdownCapability to expose this. The replicated repository also uses
this optional capability in order to control shutdown of the master and
replica.
If the builder also supported controlling shutdown behavior, I feel it
would need to be added to the standard builder interface. All builders
would need to be retrofitted to implement this new method. Other options
include reflection, casting or inventing a builder capability.
Of course the builder shutdown option could simply be defined on the few
"core" repository builders like BDB and JDBC, but it would be somewhat
inconsistent. It would also mean that there are multiple ways of
controlling the same option.

Post by Dan Washusen
I think it would be more obvious (for a user of carbonado) to have the
ability to explicitly control the addition of a shutdown before the
repository has been created, however I'd be more than happy with the
changes you mentioned below.
As this issue is corrupting jobs that take several hours to complete
I'll have to modify and re-package the carbonado code to work around
it. If the change you described below is the solution then I'll
mirror those changes on the 1.1.2 code in order to minimize the impact
of upgrading the 1.2...
Cheers,
Dan

Brian O'Neill

2008-05-22 00:45:28 UTC

Permalink

Have you tried to make the change yourself to see if it works for you? I can
then merge your changes in.

Post by Dan Washusen
Yep, that sounds reasonable; I only really use a small part of carbonado so
my suggestion was probably a little selfish... :)
Do you have an issue number I can use to monitor the code changes you make?
Cheers,
Dan

Post by Dan Washusen
I think it would be more obvious (for a user of carbonado) to have the
ability to explicitly control the addition of a shutdown before the
repository has been created, however I'd be more than happy with the
changes you mentioned below.
As this issue is corrupting jobs that take several hours to complete
I'll have to modify and re-package the carbonado code to work around
it. If the change you described below is the solution then I'll
mirror those changes on the 1.1.2 code in order to minimize the impact
of upgrading the 1.2...
Cheers,
Dan

Dan Washusen

2008-05-22 00:54:47 UTC

Permalink

I've tested my original suggestion and it works. I'll make the change you
suggested and re-test...

Post by Brian O'Neill
Have you tried to make the change yourself to see if it works for you? I
can then merge your changes in.

Post by Dan Washusen
Yep, that sounds reasonable; I only really use a small part of carbonado
so my suggestion was probably a little selfish... :)
Do you have an issue number I can use to monitor the code changes you make?
Cheers,
Dan

Post by Dan Washusen
I think it would be more obvious (for a user of carbonado) to have the
ability to explicitly control the addition of a shutdown before the
repository has been created, however I'd be more than happy with the
changes you mentioned below.
As this issue is corrupting jobs that take several hours to complete
I'll have to modify and re-package the carbonado code to work around
it. If the change you described below is the solution then I'll
mirror those changes on the 1.1.2 code in order to minimize the impact
of upgrading the 1.2...
Cheers,
Dan

Dan Washusen

2008-05-22 01:43:57 UTC

Permalink

Yep, your change works a treat...

Post by Dan Washusen
I've tested my original suggestion and it works. I'll make the change you
suggested and re-test...

Post by Brian O'Neill
Have you tried to make the change yourself to see if it works for you? I
can then merge your changes in.

Post by Dan Washusen
Yep, that sounds reasonable; I only really use a small part of carbonado
so my suggestion was probably a little selfish... :)
Do you have an issue number I can use to monitor the code changes you make?
Cheers,
Dan

Post by Dan Washusen
I think it would be more obvious (for a user of carbonado) to have the
ability to explicitly control the addition of a shutdown before the
repository has been created, however I'd be more than happy with the
changes you mentioned below.
As this issue is corrupting jobs that take several hours to complete
I'll have to modify and re-package the carbonado code to work around
it. If the change you described below is the solution then I'll
mirror those changes on the 1.1.2 code in order to minimize the impact
of upgrading the 1.2...
Cheers,
Dan

13 Replies
1 View
Permalink to this page
Disable enhanced parsing

Thread Navigation

Dan Washusen 2008-05-20 00:34:40 UTC

Dan Washusen 2008-05-20 06:56:18 UTC

Brian S O'Neill 2008-05-20 13:39:27 UTC

Brian S O'Neill 2008-05-20 14:01:50 UTC

Dan Washusen 2008-05-20 22:17:19 UTC

Brian S O'Neill 2008-05-21 02:17:43 UTC

Brian S O'Neill 2008-05-21 05:55:26 UTC

Dan Washusen 2008-05-21 06:44:22 UTC

Dan Washusen 2008-05-21 06:45:48 UTC

Brian S O'Neill 2008-05-21 13:55:57 UTC

Dan Washusen 2008-05-22 00:41:31 UTC

Brian O'Neill 2008-05-22 00:45:28 UTC

Dan Washusen 2008-05-22 00:54:47 UTC

Dan Washusen 2008-05-22 01:43:57 UTC

about - legalese