[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some observations

On Sat, 16 Dec 2000, Peter Schuller wrote:
> Hello,
> 
> > since we are speaking about internal programming, patches and such things, we
> > should take this to the dev list.
> 
> I will remove ozone-users from the recipiant list of this post.
> 
> [IOException upon connection close]
> > Yes. It was (?) a timing problem which should has been fixed. I've added a
> > sleep(1000) to ExternalDatabase.close(). This fixed the prblem for me and
> > nobody complained so far. Hmm...
> 
> Ok. I will try to have a look at it myself. If I am going to be successful
> in making contributions to the project, I need to figure out the code sooner
> or later anyway.
:)

does your test client closes the database connection before exiting?

> 
> [NullPointerException upon remote db shutdown]
> > > So, is this a known issue?
> > 
> > No, I normally don't use the admin tool. But I can reproduce the problem.
> > 
> > Peter, I'm half way done making a new admin interface and front-end. I would
> > like to completely drop the old admin API and concentrate on the new one.
> > Unfortunately currently I cannot dedicate that much time to this. I could check
> > in what I've done so far so that you can have a look. What do you think?
> 
> > This would be great.

Check out latest CVS. There is a new module ..core.admin. I'm using the
ordinary proxy/target mechanism for the admin system now. Seems to be much
easier to maintain since admin functions can now be implemented as simple
methods without the need to check command codes or something. The admin
fron-end is now a simple ozone client that connects to the server side
AdminImpl object.

So far I see two major issues here, which are not addressed yet:

- a security and authentication model to protect the admin interface

- shutting down from a ordinary database object might be a problem

> > 
> > Make a diff against the latest CVS and send the patch to the dev list. After
> > one or two valuable patches I will give you commit access to the CVS.
> 
> Ok. "I'll be back."
> 
> [Slowness]
> > This one again...
> > 
> > Peter, it is very slow to call a database object from the client. The socket
> > latency is the bottleneck. Creating/deleting your objects inside a database
> > omethod (thus inside the server) is around 1000 times faster. Please read docu
> > on this.
> 
> Yes, I do realize that it is going to be slow to do a remote access. But I
> don't understand why Ozone doesn't seem to utilize the CPU fully. In my
> experience, client/server apps running locally tend to eat the CPU 100%
> (i.e. with no internal socket latency problem).

Maybe there is a problem in the socket communication code of ozone. But
honestly, I don't expect such a problem to exist.

> 
> I *was* able to increase CPU usage slightly though after I discovered the
> java process doing most of the work was reniced to level 10 (it's the day
> the Linux JVM implements thread priorities). Seti@home (reniced at 20) was
> taking a piece of the pie. But even with Seti@home killed, I only get about
> 20-40% CPU usage, which is strange. I don't think I've ever seen such
> behavior before (since everything is local, no waiting on hardware is
> involved, so the CPU should get fully utilized (either in user space (Java)
> or kernel space (I/O and socket stuff)).

I agree, this is strange. Anyway, client-server communication will always be
very slow. I'm not sure if it's worth the time to dig that deep into this.
However, I will test this by myself. ;)


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com