ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google


Mail Archive Home | shark List | December 2004 Index

<--  Date Index  --> <--  Thread Index  -->

Re: [shark] Concerns Testing 1.0.1 release


Hi,

if using just one shark CORBA server, you can leave caches turned on, and
use it from many clients at the same time.

1) ID collision can't be caused because shark's ID generation is
synchronized on a DB.

2) it shouldn't happen so often. As we know, Rich Robinson (the contributor
that gave an idea about tnameserver restarting) used shark server for
several months, and he haven't had that many problems - maybe he could tell
us.
Maybe at the time you started shark, you've had a nameserver up, so there
was a colision?


3) we tried shark from many CORBA clients at a same time, starting a
thousands of processes, and we had no out of memory problems, but of course
it depends of what do you ask from shark - if you have a thousands of
processes in DB, and you want to get them all, you could have a problem with
memory. Your test seems OK, and it's fair enough. I've just executed test
with 5 threads each starting 1000 of processes with HSQL in the same VM (and
HSQL is not memory saving DB), and I've executed it without enlarging Java
VM, and had no problems. Is it the shark server or your client that is
having out of memory? Maybe you should comment the line:

             pi.addPerformer(proc1);


Also, turn-off LimitAgent (comment setting in Shark.conf if configuring shark 
this way), cause when you start shark with a thousands of procs in DB, it 
will take a long time until the engine is up (it's initializing the limit 
agent for each process)


Regards,
Sasa.

----- Original Message -----
From: <christopher.hunter@xxxxxxxxxxxxxx>
To: <shark@xxxxxxxxxxxxx>
Sent: Wednesday, December 15, 2004 12:09 AM
Subject: [shark] Concerns Testing 1.0.1 release


> Hello All,
>
> I basically ran into three problems of varying concern.  Is their a
fix/explanation for these findings? (Perhaps my test is invalid.) All
testing done with 1.0.1 2004-09-09 release, Shark configured to use SQL
Server 2000 database, cacheing settings disabled in shark.conf.
>
> Otherwise, love Shark and really appreciate all the work that has gone
into this so far.  I'd love to get my company participating in this project
and using Shark, but I'll have to address my concerns first.  Comments?
Help?  Guidance? Updates?
>
>
> 1. Access single shark server from multiple clients running test could
cause ID collision - ID's generated already existing, thus causing
exceptions!  (All cacheing disabled in server configuration/retest/same
problem)   Wouldn't it be better to get the ID from the database rather than
use the current getObjectID scheme?
>
> 2. tnameserv.exe dies way too easy/often - changing restart interval only
marginally successful. Server once left in MUST reboot state to recover
(manual restart of tnameserv failed too)
>
> 3. out of memory condition running heavy load test.  Code created instance
of same workflow over and over - workflow originally called ToolAgent to do
some database audit logging (to see how test was progressing), but final
test workflow basically started - stopped - doing nothing.   Still failed
under heavy test.
>
> Tests set large memory available for JVM for test code AND for JVM on
server via standard JVM command line parameters (
>
>
> Heavy test was calling this code 5000 times, sleeping 5 seconds inbetween
each call (perhaps this in an unfair test? why?):
>
>     private static void startSomeProcess(int counter)
>     {
>
>         //here we connect via CORBA to running server instance and
>         //start up a new process
>
>         String host = "sa00-dev-java";
>         String port = "10123";
>         String servername = "Shark";
>
>         String pkgId = "test_js";
>         String pDefId1="test_js_Wor1";
>
>         WorkflowService.SharkInterface sharkie =
SharkClient.findWorkflowServer(host, port, servername);
>         WorkflowService.SharkConnection sConn =
sharkie.getSharkConnection();
>
>         try
>         {
>
>             sConn.connect("admin","enhydra","","");
>
>             WorkflowModel.WfProcess
proc1=sConn.createProcess(pkgId,pDefId1);
>             ProcessInstantiator pi = new ProcessInstantiator();
>             pi.addPerformer(proc1);
>
>             proc1.start();
>             sConn.disconnect();
>
>         }
>         catch(Exception e)
>         {
>             e.printStackTrace();
>             System.out.println("WHOOPS, SOMETHING ROTTEN IN DENMARK");
>
>         }
>
>         System.out.println("Done");
>
>     }
>
>
> Initial Errors logged:
>
> Done
> Done
> Done
>
> org.omg.CORBA.UNKNOWN:   vmcid: SUN  minor code: 202 completed: Maybe
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces
sorImpl.java:39)
> at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstruc
torAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
> at java.lang.Class.newInstance0(Class.java:308)
> at java.lang.Class.newInstance(Class.java:261)
> at
com.sun.corba.se.internal.iiop.messages.ReplyMessage_1_2.getSystemException(
ReplyMessage_1_2.java:90)
> WHOOPS, SOMETHING ROTTEN IN DENMARK
> Done
> at
com.sun.corba.se.internal.iiop.ClientResponseImpl.getSystemException(ClientR
esponseImpl.java:105)
> at
com.sun.corba.se.internal.corba.ClientDelegate.invoke(ClientDelegate.java:31
4)
> at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457)
> at
WorkflowService._SharkConnectionStub.createProcess(_SharkConnectionStub.java
:95)
> at com.safeharbor.ztest.TestStuff.startSomeProcess(TestStuff.java:114)
> at com.safeharbor.ztest.TestStuff.main(TestStuff.java:90)
> org.omg.CORBA.UNKNOWN:   vmcid: SUN  minor code: 202 completed: Maybe
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces
sorImpl.java:39)
> at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstruc
torAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
> at java.lang.Class.newInstance0(Class.java:308)
> at java.lang.Class.newInstance(Class.java:261)
> at
com.sun.corba.se.internal.iiop.messages.ReplyMessage_1_2.getSystemException(
ReplyMessage_1_2.java:90)
> at
com.sun.corba.se.internal.iiop.ClientResponseImpl.getSystemException(ClientR
esponseImpl.java:105)
> at
com.sun.corba.se.internal.corba.ClientDelegate.invoke(ClientDelegate.java:31
4)
> at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457)
> at
WorkflowService._SharkConnectionStub.createProcess(_SharkConnectionStub.java
:95)
> at com.safeharbor.ztest.TestStuff.startSomeProcess(TestStuff.java:114)
> at com.safeharbor.ztest.TestStuff.main(TestStuff.java:90)
> WHOOPS, SOMETHING ROTTEN IN DENMARK
> Done
> org.omg.CORBA.UNKNOWN:   vmcid: SUN  minor code: 202 completed: Maybe
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces
sorImpl.java:39)
> at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstruc
torAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
> at java.lang.Class.newInstance0(Class.java:308)
> at java.lang.Class.newInstance(Class.java:261)
> at
com.sun.corba.se.internal.iiop.messages.ReplyMessage_1_2.getSystemException(
ReplyMessage_1_2.java:90)WHOOPS, SOMETHING ROTTEN IN DENMARK
> Done
>
> ..ETC..
>
>
> Then finally various errors - all with out of memory as root cause (things
get squirrely when out of memory)
>
>
>


----------------------------------------------------------------------------
----


>
> --
> You receive this message as a subscriber of the shark@xxxxxxxxxxxxx
mailing list.
> To unsubscribe: mailto:shark-unsubscribe@xxxxxxxxxxxxx
> For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>








<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.