RE: Does anyone else have this glitch ??

Hi Monique,

A bit of info first, I'm using a CVS Version of shark which is probably the
same as Shark 1.1-2, Shark is running in tomcat and should be running in a
single thread all on it's lonesom. IO Have got caching Disabled, as I Access
and test processes from my Dev Workstation as well.

I Haven't hit this problem in the last 2 day's or so, but then again I Nukes
the database on Monday morning, so I'll let it grow and monitor the status
over the rest of this week, I've got a process I use for checkin the
execution times - etc.. So I'll run it regularely to see how the performance
is when the database size grows. (Currently it's at 40 Mb).

Looking at my XPDL's there a a few places where there are 5-10 "Automatic"
Activities in a row, I'll try to Optimise this (I Was planning to get the
processes to split and run in "parallel" in any case).

I'll let everyone know how the performance is by the end of the week, I'm
still having the JMS Client check out as well.

Cheers

Neville van Deventer

-----Original Message-----
From: Monique Maker [mailto:[email protected]] 
Sent: 26 July 2005 02:38 PM
To: [email protected]
Subject: Re: [shark] Does anyone else have this glitch ??

Hello Neville,

Recently Shark guys told us that Shark recalculates processes state
"greedy". This means that Shark recalculates all "automatic" activities in
row. In this sense, there might be situation when Shark locks a process for
evaluation of several activities in sequence. The total evaluation time in
this case might be more than the allowed lock time.

Shark persists and retrieves the needed objects for each activity. If you
have disabled caching in shark.config, and your database slows down due to
Shark data volume, this will additionally increase the process state
evaluation time. I think it would be a good idea to measure the time of
execution for one and the same process definition on your full database and
on an empty database.

Which Shark version you are using? Are you using Shark in several threads?

You might also try to disable recalculation of all deadlines (in version
1.1-2) - set Deadlines.reevaluateDeadlines=true
in your shark.config. As we browsed through Shark code it seems this option
will reduce the number of processes to be evaluated.

Best Regards,
Monique


Neville van Deventer wrote:
> Hi Rusi,
> 
> Thanks for the Information,
> 
> Most of my activities, call a wrapper in one form or the other, Some 
> wrappers are using a JMS Client to call the MDB's to retrieve the 
> information required, or to set information to the Database, all I can 
> gather from the information you have provided me is that one or more 
> of these wrappers are "Hanging" for some or other reason, I've got 
> timers on all the JMS wrappers and so far none of them are taking 
> longer than 500ms to complete it's function. I had some problems with 
> the MDB's hanging if a runtime exception was thrown, but the other 
> senior fixed that issue to ensure that the MDB's and the JMS Client 
> will always Return Timeously. I've also added a Timeout on the XPDL of
60s, Just in case.
> 
> Perhaps one of the MDB's are not catching the runtimes properly, so 
> I'll have them check it out again.
> 
> As for the BaseExceptions, It looks like the Locks are happening when 
> the Deadlines are checked, and looking back at my code, I am catching 
> it and doing nothing (Not printing stack, etc...)
> 
> Once again, thanks for the info.
> 
> Neville
> 
> -----Original Message-----
> From: Rusi Popov [mailto:[email protected]]
> Sent: 26 July 2005 08:36 AM
> To: [email protected]
> Subject: RE: [shark] Does anyone else have this glitch ??
> 
> Dear colleague,
> We had a very similar problem - when a process has an activity that 
> runs long, the process is locked until this activity ends. In a 
> multithreaded application usually there are other threads that need to 
> check the status of the same process instance while this activity is 
> running. IFAIK all public Shark methods that work with a process or 
> activity instance try to obtain a lock in the process through 
> *LockMaster classes (i.e. DODSLockMaster). Once the activity is still 
> running, the process instance is locked and the other thread cannot 
> obtain new lock on it. Then the *LockMaster.lock() throws a BaseException.
> Your problem might be related indirectly with the database volume (by 
> the way, we use Oracle) - activities just run slower while other 
> threads are trying to lock the process.
> Our solution:
> We changed our application to catch the BaseExceptions, not report 
> them and treat them as "the process is busy". In addition we changed 
> our application not to rely on information that might be retrieved 
> from a process instance while it is still locked
> 
> Just a guess:
> Probably your activities highly depend on the database volume so you 
> should try to optimize their SQL statements or try to index the db tables
they use.
> With best regards
> Rusi Popov
>  
> -----Original Message-----
> From: Neville van Deventer [mailto:[email protected]]
> Sent: Monday, 25 July, 2005 22:52
> To: [email protected]
> Subject: [shark] Does anyone else have this glitch ??
> 
> 
> Hi List,
>  
> When my Shark Database reaches a size of about 1G, the shark library 
> has trouble following transitions correctly, and I'm getting a lot of 
> DODS Lock exceptions.
> 
> Just wanted yo knopw if anyone else is experiencing this type of glitch ??
> 
> Thanks in Advance
> 
> 
> Neville van Deventer
> 
> 
> 
> 
> 
>

--
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws