Linux/Postgres update ...
bmurray at snf.stanford.edu
Wed Mar 27 10:06:35 PST 2002
That's interesting. I think we'll need to put some debugging output in
the servers on spf to track this down.
JavaOne is great, but the days are long. Also, I can't get access to
my mail from the conference. No ssh.
Talk to you soon,
On Tue, 26 Mar 2002, John Shott wrote:
> Bill and Mike:
> I hope that things are going well at Java One.
> I've made a bit of progress here:
> 1. rsync now works to/from guilden ... crle problem on guilden.
> 2. Guilden servers can now connect to the postgres database on spf ... it
> turns out
> that spf still had a 192.168.0.103 entry on guilden:/etc/hosts (instead of
> 3. Minor cleanup of makefile stuff.
> The resource client exception that results in the "Unmarshaller" problem when
> we try to fire up the resource client is definitely more related to the
> database than to the server ... even though it is the client that seems to
> notice the problem.
> Here is what I find ...
> 1. Client running on bopeep against servers on guilden against the postgres
> database on spf ... resource client fails.
> 2. Change the database from Postgres (on spf) to Oracle (on bopeep) and
> everything is fine.
> 3. Client running on shott against servers on spf against ther oracle database
> on bopeep .... everything is fine.
> 4. Change the database from Oracle (on bopeep) to Postgres (on spf) and the
> resource client fails.
> What is surprising, however, is the fact that the resource manager seems to
> think that it read all of the member/projects/accounts from either Postgres or
> Oracle ... but the client seems to develop a problem if that data came from
> the Postgres database.
> I'm sort of wondering whether the server is getting some sort of twisted
> information when it does it's getAllMembers call ... but not twisted enough to
> cause it to complain ... but that when it tries to pass it on to the client
> that everything is OK.
> Wierd ...
> Oh well, talk to you soon,
More information about the coral