Re: [stellation-res] Stellation on Mckoi

["Snow" <snowl@xxxxxxx>]

Mark C. Chu-Carroll wrote:
> On Tue, 2003-07-22 at 13:59, Snow wrote:
> We can't take this contribution. McKoi is GPL; Stellation is CPL.
> The two are not compatible. Therefore we cannot include McKoi
> support in our distribution of Stellation.

I know Mckoi can't be distributed with Stellation, but there is no
(compile-time) dependancy on Mckoi in what I wrote.

> this is the agreement that
> we struck with the lawyers in order to get permission to
> do this project as open-source - we have to scrupulously stick
> to their license interpretations, and they say we can't do this.)

Fair enough. I think that's a non-standard interpretation, but if them's the
rules, then them's the rules.

> > I've been trying to get Stellation running on the Mckoi DB. Mckoi can
run
> > either standalone (DB in its own JVM) and embedded (where the DB engine
is
> > in the Stellation JVM).
> >
> > As far as SQL is concerned there were two small problems:
> > 1) Mckoi doesn't like having 'REFERENCE' after column definitions. Since
> > these seem to duplicate the FOREIGN KEY constaint, removing them fixed
the
> > problem.
> > 2) I had to turn off case-sensitivity in mckoi.
>
> That shouldn't be too hard using the database layer. I assume this
> wasn't too painful. Are there any changes that you would suggest to
> the docs based on doing this?

Not that I can remember. I was making the email up as I went along so any
details I felt at the time should be noted have already been noted.

> Don't put a lot of effort into it. Before too long...

Just to be clear I sent the email because I wasn't expecting to find time to
carry on my efforts to a logical conclusion in the near future. Also bear in
mind that everything I said was from a build 1-2 months ago so the
bugs/problems I mentioned may now be gone, and I don't remember a great deal
about them now anyway.

With regard to bugzilla. I will try to make time to reproduce the bugs I
mentioned in the next couple of weeks and give you the additional details
you requested. Would you like me to wait until I have confirmed they still
exist, or just put them in now anyway?

> we're going to
> discard location strings in favor of multiple command-line
> parameters.
>
> Much better, neh?)

From what I remember the main problem was that the DB url was being split up
into several pieces and I couldn't get them back together again in the right
order. Better to keep that part as one unit. Though for Stellation's details
splitting them up is probably a good idea.

> ^Z on a blank line should work; there's a fix that I haven't checked
> in yet which also allows "." on a blank line (and generates a message
> to tell you that).

I may not having been doing it on a blank line. Should probably say that
here:
(http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/org.eclipse.stellat
ion/plugins/org.eclipse.stellation.core/doc/tutorial.html#option-comment).

> > the memory
> > usage goes up rapidly (200MB+). Is this normal? I thought it might be
the
> > JDK1.4.1/JDOM bug, but I tried JDK1.4.0 and it still happened.
>
> I think that's McKOI. The Stellation scripts limit the memory size that
> the JVM is allowed to allocate to 160M.

My recall of this is very vague, but I'm pretty sure it wasn't Mckoi's VM
whos memory was increasing. I can't remember whether it was the Stellation
client or server; if it was the server it may still have been the Mckoi
drivers, but I have a feeling I had eliminated Mckoi from suspicion somehow.
Also I had increased the stellation VM's memory several times from the
default to try and do the check-in (I never succeeded).

> Usernames shouldn't have spaces.

You should tell that to that nice Mr Gates. His programs give usernames like
'Fred Bloggs' by default. That said I can't remember why I had my Windows
username in a Stellation bat.

> > 6) On Windows getCanonicalizedName() is v. v. slow.
>
> Due to lack of windows knowledge, neither me, nor the person who wrote
> the command-line interface knew that. Do you know of an efficient
> alternative that will do the same job?

I can't remember how I came to the above conclusion, but I usually profile
by pressing ctrl-break at lot (Linux ctrl-\). So it may not be an accurate
measure of the performance problem. Nor do I know a work-around if it is the
problem.

> > However
> > whenever I tried to connect to it (from the Win machine) it would just
> > freeze. Looking at the thread dumps both ends seem to be reading (though
the
> > IBM JDK thread-dump is quite hard to read so I may be wrong).
>
>
> I would appreciate it if you could send me command-line transripts of
> running tsvcadmin an linux with --debug=2, as well as a copy of the
> JDK thread dump. I'd like to try to see what's going wrong.

OK, but again it might take a week or two.

-- 
Snow