Hal,
Hal Vaughan wrote:
On Thursday 10 May 2007 04:24, Kay Ramme - Sun Germany - Hamburg wrote:
Hal,
Hal Vaughan wrote:
On Thursday 10 May 2007 03:12, Kay Ramme - Sun Germany - Hamburg
wrote:
Hi guys,
if you are stumbling over deadlocks in OOo, it would be nice if
you can submit issues for that, ideally with some tests to
reproduce it and some stacktraces. If I remember correctly, there
is already a tool coming with OOo, which allows to kill it while
sending stacks at the same time.
Unfortunately, it's not happening on my systems anymore, it's
happening on my customer's systems and that's not a situation where
I can go through that. This doesn't happen often, but it was
starting to happen to one client on Windows XP and she had to
reboot every time she wanted to run my app. I have to set up a
kill method first, then some VERY major programming to handle tasks
that, at this time, take me days to do.
If you see a way to do so, please submit issues. Feel free to assign
these to me first ([EMAIL PROTECTED]), I am going to dispatch these
to the rights owners than. By the way, using multiple clients at the
same time likely leads to deadlocks / crashes, because of issues in
OOos implementation relative to multi-threading.
I've wondered if it might be a multiple clients issue (and here it makes
it hard to keep track, since we're talking about server/clients and my
business clients, so I'll use "client apps" to refer to the non-human
one). Basically this is not a program people will keep on in the
background. It runs, does it's thing, then exits. When it's done, as
I said, it checks a flag to see if OOo was running when it started. If
not, it kills OOo through the API. If OOo was running, it cleans up
and exits properly. Most of the time there's never been a problem, but
it started showing up with one user after a while.
You may want to use multiple instances of OOo running, one for every
client (you need to provide directories for the user data for every
instance, e.g. "-env:UserInstallation=<path>"). So, obviously this is
not optimal memory wise ;-)
I've wondered if, for some reason, the old instance of the client app
was not releasing, but the log files show it was.
You mean, it terminated ?!
I think I'm going to handle this by writing a routine that will kill
OOo. When my app first starts, it'll try an immediate connection with
OOo. If it doesn't get it, it'll run OOo and wait. If, after a
certain length of time, it doesn't get a connection, then it'll kill
any instance of OOo and try again. At the end, it'll release it and if
it was supposed to end OOo, it'll also terminate it with Taskkill.
SAL implements a little executable called "kill.exe", which is somewhat
similar to the Unix kill command, but is usable on Windows
(http://porting.openoffice.org/source/browse/porting/sal/systools/win32/kill/).
Call "kill -null <pid>" to terminate the hanging process, while ensuring
that the crash reporter jumps up.
The only situation that doesn't cover is checking to see if everything
is okay if OOo was already running and is left running at the end. I
could try getting another connection and releasing it to be sure, but
that gets redundant.
OOo is currently missing a precise process lifecycle wrt. to Uno
clients. Please see
http://udk.openoffice.org/issues/show_bug.cgi?id=63473 for details.
I appreciate your offer and will make sure, in the future, that I do
assign any bugs I report to you directly. I don't think you'll see any
for a while, since the programming I need to do limits my time so much
that, for now, the only use of OOo is generally for the app I'm working
with, which means I'm essentially doing only a few limited things over
and over. When I have time to get back to writing screenplays, I'll be
developing a number of specialized macros and working with margin
changing and other things that I'll be using in ways most people either
don't use as often as I need to do or don't use in the way I do. When
I'm doing that, I'll certainly be watching for bugs.
OK
On another note, I have tried to report a couple issues in the
past. One was in Writer and it was closed because it could not be
reproduced for presentations. The other was a serious issue about
importing documents. In that one I was totally blown off and I
felt some of the comments bordered on rude.
I am sorry for that. Rude comments etc. are certainly _not_
acceptable at all. If you point to me to the issues, I take a look.
I'd have to search for them. One, the issue I had in Writer, seems to
be fixed now, in spite of the weak troubleshooting and the other was
taken care of with the Word Perfect import margin, which came along a
few years later.
OK
I'm really loathe to turn in bug reports at this point. I've
helped with the community before while working out macros and macro
programming. I've been working in Perl for 6 years and in Java for
about 4 years, but I've never learned C and it seems C and C++
programmers seem to have completely different attitudes and a
language all their own. Unfortunately, and I've come across this
in several FOSS projects, part of that language seems to include
being condescending to those who aren't in "their" world.
Again, I am sorry for that. My understanding is, that we are a
community, helping each other to reach the bigger goal. This includes
expressing things in an understandable language and showing respect
for each other.
Yes, I agree. That's why I was working with people on macros and issues
around that. Some of my questions even ended up in Andrew's book on
macros in OOo. The people there were quite helpful and it was a good
community, so I was glad to work with them and wanted to help. On the
other hand, when a programmer got snotty with me, it was years before I
even considered filing any kind of issue again. I've dealt with that
attitude before and, as a former special ed teacher, I found it quite
disgusting. My job was to work with people that didn't understand in
the same way as others and I had to show much more tolerance than most
people ever do. I've dealt with a few other situations where
developers were almost hostile toward those they considered "end users"
because the users did not have the same technical skills the
programmers did. It's totally inappropriate and it had happened with
me in a few other FOSS projects, so I just gave up on filing bug
reports. If developers want help but aren't willing to treat those who
try to help like humans, then I'm just not going to take the risk.
Understood. My believe is, that there are no end users respectively
developers, everybody has always more than one role, e.g. being a user
of a browser while developing a word processor or some web stuff (this
obviously does not need to be computer related only :-). So I think,
that everybody should be able to understand the position of others
relative to ones own. Moving along from being a novice e.g. to becoming
a wizard is matter of many small steps in learning etc. Any (artificial)
barrier between any pair of those steps hinder people to learn and to
improve their abilities. This is also one of the reasons I am completely
against something as "developer" documentation vs. "end user"
documentation.
As I said, I've helped in other areas and when I get back to the
point where I'm writing again, instead of programming, I'm sure
I'll have a lot to contribute to in OOo. It's been a big help to
me and I want to give back more than what I have, but I've just
found reporting issues to be a negative experience. I don't know
if the intent of some of those programmers was to squelch me so
they could close the bugs, but the effect is that I've learned it's
not worth the hassle to report issues.
There sure are cases, where opinions very, mostly I would trust the
aspect matter expert, so certainly she or he may fail.
My sense was that in at least one case, the intent was to just get me to
shut up so the issue could be closed and forgotten.
This is certainly not acceptable. Please put me on CC: if you ever
stumble over this again.
Hal
Best regards
Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
