[Mulgara-dev] XSD Date/Time Corruption reproducible

Paul Gearon gearon at ieee.org
Wed Jan 24 22:37:07 UTC 2007


Hi David,

It looks like you are debugging the client and not the server.

There *is* no source for RemoteSessionImpl_Stub, since this is created by
rmic.  All this class does is package up the parameters, send them via RMI
and wait for the return value (or a RemoteException).

I've never had a problem with Eclipse for debugging.  Set a breakpoint in a
central spot like:
src/jar/resolver/java/org/mulgara/resolver/MulgaraTransaction.java:195.
This is in the execute(Operation,ResolverSessionFactory,DatabaseMetadata)
method.

Then tell it to execute using the main() method in
org.mulgara.server.EmbeddedMulgaraServer.  Everything should start up as per
usual.  Then run a client normally, and issue the queries you want.  While
the client is waiting for its answer, the server will stop at the point you
marked.



On a different topic, I might describe the name of the class you were
talking about:  RemoteSessionWrapperSession  (No, this naming scheme was NOT
mine).

The name can be broken down into 2 parts: "Remote-Session Wrapper" and
"Session".  The first part means that this class wraps a "Remote-Session".
So it hides an RMI interface.  The main characteristic of an RMI interface
is that every method can throw a RemoteException.  The wrapper calls through
to the underlying RemoteSession object, and catches any RemoteExceptions
that may be thrown.

The second part of the name is "Session".  That means that the class meets
the "Session" interface.  So from the perspective of calling code, it will
see a Session object, and will never have to worry about RemoteException.
So the calling code is blissfully unaware of the RMI layer.  I believe that
the idea was to make it possible to remove the RMI layer entirely, and have
the Session object at the server end fit into the place of this
RemoteSessionWrapperSession.

At the server end there is a similar class called
SessionWrapperRemoteSession.  Similarly, this class wraps the real Session
object, and presents a RemoteSession interface.  All this class does is
declare that every method throws a RemoteException, and then pass the call
down to the underlying Session object.  Throwing RemoteException is a
requirement for RMI to call these methods.

You will see similar naming schemes for other objects as well (the one that
comes to mind is
Answer/RemoteAnswer/AnswerWrapperRemoteAnswer/RemoteAnswerWrapperAnswer).

They're terrible names, but they *do* tell you what is going on.

Regards,
Paul Gearon

On 1/24/07, David Moll <DMoll at viewpointusa.com> wrote:
>
>
> > The place to start looking is in the localisation/globalisation code
> > - so that is LocalizedTuples, StringPoolSession, and
> > GlobalizedAnswer, and move out from there.
>
> I've been looking at these classes and I'm not making much headway.
> There also wasn't much logging currently existing in those classes.  I
> decided to go and find a debugger - I wasn't able to get Eclipse to
> debug EmbeddedMulgaraServer.java.  I grabbed two plugins - JarPlug and
> JarLaunch - that allow me to launch mulgara-1.0.0.jar in debug mode.
>
> I figured this would be the easiest way to see what was happening and
> where the code was going.  I managed to follow it to the insert method
> of org.mulgara.server.rmi.RemoteSessionWrapperSession.java.
>
>   public void insert(URI modelURI, Set statements) throws QueryException
> {
>
>     try {
>
>       remoteSession.insert(modelURI, statements);
>       resetRetries();
>     }
>     catch (RemoteException e) {
>
>       testRetry(e);
>       insert(modelURI, statements);
>     }
>   }
> But at line 235, the " remoteSession.insert(modelURI, statements); ", I
> can't step any further.  Also, the remoteSession appears to be an
> instance of RemoteSessionImpl_Stub, for which I can't find a source
> file.
>
> I know that the developers don't do Mulgara development in Eclipse -
> what are you using for breakpoints and debugging?  Or are you adhering
> to the model of using the Logger for debugging?
>
> So I have not yet managed to find where the conversion from 02:56 to
> 03:56 has happened yet.
>
> ~Dave
> _______________________________________________
> Mulgara-dev mailing list
> Mulgara-dev at mulgara.org
> http://mulgara.org/mailman/listinfo/mulgara-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mulgara.org/pipermail/mulgara-dev/attachments/20070124/3530f8fa/attachment.htm>


More information about the Mulgara-dev mailing list