This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 29166 - Memory-based Repository cannot be used after it is shutdown
Summary: Memory-based Repository cannot be used after it is shutdown
Status: RESOLVED WONTFIX
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P4 blocker (vote)
Assignee: David Strupl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-11-29 05:12 UTC by _ briansmith
Modified: 2010-09-23 09:14 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
MemoryRebootFailure test case (standalone program, run with "java MemoryRebootFailure" and "java MemoryRebootFailure memory" (1.30 KB, text/plain)
2002-11-29 05:14 UTC, _ briansmith
Details
Another testcase, this time using two seperate repositories (814 bytes, text/plain)
2002-12-12 09:00 UTC, _ briansmith
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ briansmith 2002-11-29 05:12:40 UTC
The B-Tree storage can initialized, shutdown,
reused again, and shutdown again. However, when
the memory storage for a repository then it stops
working after the call to shutdown(). In
particular, if using the memory-based storage and
the default standalone MDRManager, then after
calling MDRManager.getDefault().shutdownAll(), the
repository is no longer usable. 

I will attach a simple testcase. To run it, you
must have all of the MDR jars in your classpath
plus a JAXP implementation (e.g. by running it
with JDK 1.4).

First, try running it without any argument. This
will use the default (Btree) storage and works
without error. Then, delete the
MemoryRebootFailure.bt? files. Then, run the
program again using "memory" as the argument. This
will use the memory based storage. The program
fails during the second pass, after
MDRManager.getDefault().shutdownAll() has been
called once already.

This is not a critical issue for me; I just
happened to find it during my own performance
testing where I was initializing and shutting down
the repository in a loop. I simply rewrote my test
to move the call to MDRManager.shutdownAll()
outside the loop (I wasn't intending to test
startup/shutdown performance anyway).
Comment 1 _ briansmith 2002-11-29 05:14:02 UTC
Created attachment 8104 [details]
MemoryRebootFailure test case (standalone program, run with "java MemoryRebootFailure" and "java MemoryRebootFailure memory"
Comment 2 Martin Matula 2002-11-29 10:07:58 UTC
Hi Brian,
this is currently "as designed". In fact the issue is that 
BTree does not fail after shutdown. It should. After 
shutdown some things may not work (such as event 
dispatching, etc.) This probably can be changed, but to 
request the change (to enable using MDR after shutdown) 
you should file a new enhancement request rather than 
issue.
So I take this issue as a request to fix the MDR so that 
any storage fails after using it after shutdown (and I 
lowered the priority to P4)
Comment 3 _ briansmith 2002-12-12 09:00:07 UTC
Created attachment 8275 [details]
Another testcase, this time using two seperate repositories
Comment 4 _ briansmith 2002-12-12 09:03:55 UTC
I attached another testcase. In this test, I am not accessing the same
repository after shutting it down. In fact, I never shut down the
repository at all. Instead, I try to create two memory-based
repositories at once. The behavior is the same whether or not the
repository is shut down in between passes. That is, once one
memory-based repository has been created, it is not possible to create
another one, whether or not the first one is shut down. 

The stacktraces that are logged are basically identical between the
two testcases. That is why I am including it in this bug instead of
filing a new report.
Comment 5 David Strupl 2010-09-23 09:14:03 UTC
I am closing all reports in category Java/Unsupported as wontfix. These should
be dead issues --- if the reported cases are against some live part of the
NetBeans IDE please reopen and we can discuss to which category they belong.