A lock could not be obtained within the time requested

[ericp56]

Hello,

I used the monitoring tools to monitor our Geronimo servers.

I've now removed all the servers, views, etc. from the monitoring app.  I even restarted Geronimo.

However, whenever I run a command on the ArchiveMRCDB, like "delete from MONITOR.STATISTICS" I get the following SQL exception: A lock could not be obtained within the time requested

How can I go about figuring out what's wrong?

Update:  Right now I'm looking at http://db.apache.org/derby/docs/10.4/ref/  which is promising.


Eric

[djencks]

Is there a stack trace with this you could show?  Also, which geronimo  
version?

thanks
david jencks

On Oct 6, 2009, at 9:03 AM, ericp56 wrote:

>
> Hello,
>
> I used the monitoring tools to monitor our Geronimo servers.
>
> I've now removed all the servers, views, etc. from the monitoring  
> app.  I
> even restarted Geronimo.
>
> However, whenever I run a command on the ArchiveMRCDB, like "delete  
> from
> MONITOR.STATISTICS" I get the following SQL exception: A lock could  
> not be
> obtained within the time requested
>
> How can I go about figuring out what's wrong?
>
> Eric
>
> --
> View this message in context: http://www.nabble.com/A-lock-could-not-be-obtained-within-the-time-requested-tp25771661s134p25771661.html
> Sent from the Apache Geronimo - Users mailing list archive at  
> Nabble.com.
>

[ericp56]

I'm using 2.1.3.  There is no stack trace that's useful.  It's just that there are lock on the table, even there is nothing being monitored, or listed as being monitored under monitoring:

Running this command in ActiveMRCDB:
select * from SYSCS_DIAG.STATEMENT_CACHE

I see lots of entries like this:
  SELECT S.statsValueList AS statsValueList, M.statsNameList AS statsNameList, S.snapshot_time AS snapshot_time, M.mbeanName AS mbeanName FROM Statistics S, MBeans M WHERE S.snapshot_time=1242698019775 AND S.mbeanId=M.id

In ArchiveMRCDB, I see lots of these:

INSERT INTO Statistics (snapshot_time, statsValueList, mbeanId) VALUES (1242875019775,'0,0,0,-1,0,0,0,0,0,0,1',68)

Apparently there's still a flurry of monitoring activity going on.

Eric

[ericp56]

Now, the disk space is used up by the Derby ArvhiveMRCDB.

Ugh!

[Jay D. McHugh-3]

Eric,

How did you remove all of the servers, views, etc?  Did you use whatever
tools are available in the monitoring system or did you delete them
directly from the database?

If you are trying to completely reset monitoring you could try stopping
the server and then deleting:

$GERONIMO_HOME/var/derby/ActiveMRCDB
and
$GERONIMO_HOME/var/derby/ArchiveMRCDB

Then restarting the server.  But I am not familiar with the nuts and
bolts of the monitoring system.

It sounds like all of the monitors that you set up are continuing to run
and capture data.

Jay
ericp56 wrote:

> Hello,
>
> I used the monitoring tools to monitor our Geronimo servers.
>
> I've now removed all the servers, views, etc. from the monitoring app.  I
> even restarted Geronimo.
>
> However, whenever I run a command on the ArchiveMRCDB, like "delete from
> MONITOR.STATISTICS" I get the following SQL exception: A lock could not be
> obtained within the time requested
>
> How can I go about figuring out what's wrong?
>
> Eric
>

[ericp56]

I used the Monitoring pages in the Web Console.

I think it may have been that I added a server in the Monitoring section, had some items monitored on the server, and then removed the server.  however, I went back and added the server again, removed everything from being monitored and then deleted it again, to no avail.

I tested removing the MRCDB databases on my local machine and started up G, and G recreated the DBs.  That looks promising.

Seeing that it's a production system, I'll have to wait for the off-hours before trying this.

Thanks,

Eric

[Quintin Beukes-2]

That might just be what caused it - removing the server while there
are dependencies on it. Geronimo has a few of these. I usually take
care to not remove anything until I'm sure nothing else depends on it.

So you would probably have to take a manual route and remove the
dependent objects, and start over creating them.

Quintin Beukes



On Thu, Oct 8, 2009 at 1:17 AM, ericp56 <eric.phetteplace@...> wrote:

>
> I used the Monitoring pages in the Web Console.
>
> I think it may have been that I added a server in the Monitoring section,
> had some items monitored on the server, and then removed the server.
> however, I went back and added the server again, removed everything from
> being monitored and then deleted it again, to no avail.
>
> I tested removing the MRCDB databases on my local machine and started up G,
> and G recreated the DBs.  That looks promising.
>
> Seeing that it's a production system, I'll have to wait for the off-hours
> before trying this.
>
> Thanks,
>
> Eric
> --
> View this message in context: http://www.nabble.com/A-lock-could-not-be-obtained-within-the-time-requested-tp25771661s134p25796067.html
> Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
>
>

[ericp56]

Everything is running smoothly now:)

In review:

1.  ArchiveMRCDB used up all of my disk space.
2.  Seeing that I couldn't bound the server at the time, I did:
          cat /dev/null > [the seg0 files in the Archive Derby DB]
3.  At a convenient time, I stopped Geronimo.
4.  Under var/derby, I did rm -fr ArchiveMRCDB
5.  Step 2 hosed monitoring, and I had to copy var/monitoring/snapshot-config.xml from another server.  
6.  I restarted Geronimo.


Eric