[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster-devel] LOCAL not working?
Hi,
I did a commit of my changes; hope that was ok. There is a test of the
LOCAL protocol (and GlobaUtil) in
org.xmlBlaster.test.client.TestLocalProtocol. However I am not sure if
it is included in when running the complete suite. I am not even sure it
will even work inside that, since it starts an embedded XmlBlaster
server.
By the way, debugging Jacorb is really hard. Including some debug stuff
makes the bug disappear or become more seldom.
I do have some traces which points in the direction that the waiting
thread will be awakened without any reply being received. Which part of
Jacorb that does this, or why no reply ever get received for these cases
I have not been able to find out.
//Peter
On Thu, 2003-09-18 at 10:29, Marcel Ruff wrote:
> Peter Antman wrote:
> > Meetings all day yesterday, but now I have something that works; but as
> > far as I understand it not designed exactly the way your stuff seems to
> > be heading.
> >
> > Here's the deal:
> >
> > You must use a Global which contains the serverside engine global in its
> > ObjectEntry "ServerNodeScope". The cloning process for each
> > XmlBlasterAccess instance must therefore include ServerNodeScope.
> >
> > The LocalConnections is simple: look up the engine.Global, get the stuff
> > you need from it and just delegate.
> >
> > LocalCallbackImpl must also have access to the engine.Global. There it
> > simply adds itself as an ObjectEntry with its raw adress as key. It
> > implements a new interface ServerNodeScope wich the serverside callback
> > expect to find in the ObjectEntry.
>
> The coolest way would be if we could get a pointer of the
> callback instance which we pass as a string and
> the ask the classloader to resolve the object instance
> again from this pointer (like in C).
>
> This is the stringified object on CORBA:
> <callback type='IOR'>
> IOR:10000010033200000099000010....
> </callback>
>
> A LOCAL 'pointer':
> <callback type='LOCAL'>
> 0x68F44A
> </callback>
>
>
> lc = (I_LocalCallback)Classloader.getObject("0x68F44A");
>
> This way we don't need to pass it via Global.
>
> But i think this is not possible in Java.
>
> So putting the object into a hashtable in Global
> (made unique with hashCode()) and retrieve it
> again as you do is probably the best way.
>
> <callback type='LOCAL'>
> LOCAL:0x3456556
> </callback>
>
> >
> > Here are some snippets from LocalCallbackImpl:
> >
> > public synchronized final void initialize(Global glob, String
> > loginName,
> > CallbackAddress callbackAddress,
> > I_CallbackExtended cbClient) throws XmlBlasterException {
> > this.glob = (glob == null) ? Global.instance() : glob;
> > this.log = this.glob.getLog("local");
> > this.ME = "LocalCallbackImpl-" + loginName;
> > this.callbackId = "LOCAL:"+this.hashCode();
> > this.cbClient = cbClient;
> >
> > // Set this object an the engine.Global so that the server cb
> > handler
> > // can find it.
> > engineGlob =
> > (org.xmlBlaster.engine.Global)glob.getObjectEntry("ServerNodeScope");
> > if (engineGlob == null)
> > throw new XmlBlasterException(this.glob,
> > ErrorCode.INTERNAL_UNKNOWN, ME + ".init", "could not retreive the
> > ServerNodeScope. Am I really on the server side ?");
> >
> > // Ad the driver to the "naming" store.
> > engineGlob.addObjectEntry(callbackId,this);
> >
> > }
> >
> > public String getCbAddress() throws XmlBlasterException {
> > return callbackId;
> > }
> >
> > public String[] update(String cbSessionId, MsgUnitRaw[] msgUnitArr)
> > throws XmlBlasterException
> > {
> > if (msgUnitArr == null) throw new XmlBlasterException(ME,
> > "Received update of null message");
> > if (log.CALL) log.call(ME, "Entering update(" + cbSessionId + ")
> > of " + msgUnitArr.length + " messages");
> >
> > return cbClient.update(cbSessionId, msgUnitArr);
> > }
> >
> > The serverside part is CallbackLocalDriver. Its job is to lookup the
> > client part in the ObjectEntry and just delegate to it.
> >
> > public final void init(Global glob, CallbackAddress callbackAddress)
> > throws XmlBlasterException {
> > this.glob = glob;
> > this.log = glob.getLog("local");
> > this.callbackAddress = callbackAddress;
> > String callbackId = callbackAddress.getRawAddress();
> > try {
> > localCallback = ( I_LocalCallback
> > )glob.getObjectEntry(callbackId);
> >
> > if ( localCallback == null) {
> > throw new XmlBlasterException(this.glob,
> > ErrorCode.INTERNAL_UNKNOWN, ME + ".init", "could not retreive the
> > LocalCallbackImpl, was there really one started");
> > } // end of if ()
> >
> > }
> > catch (Throwable e) {
> > log.error(ME, "The given callback id ='" + callbackId + "' is
> > invalid: " + e.toString());
> > throw new XmlBlasterException(glob,
> > ErrorCode.RESOURCE_CONFIGURATION_ADDRESS, "Local-CallbackHandleInvalid",
> > "The given callback Id is invalid: " + e.toString());
> > }
> > }
> >
> > public final String[] sendUpdate(MsgUnitRaw[] msgArr) throws
> > XmlBlasterException
> > {
> > if (msgArr == null || msgArr.length < 1)
> > throw new XmlBlasterException(glob,
> > ErrorCode.INTERNAL_ILLEGALARGUMENT, ME, "Illegal sendUpdate()
> > argument");
> > if (log.TRACE) log.trace(ME, "xmlBlaster.update() to " +
> > callbackAddress.getSecretSessionId());
> >
> > try {
> > return
> > localCallback.update(callbackAddress.getSecretSessionId(), msgArr);
> > } catch (XmlBlasterException xmlBlasterException) {
> >
> > // WE ONLY ACCEPT ErrorCode.USER... FROM CLIENTS !
> > if (xmlBlasterException.isUser())
> > throw xmlBlasterException;
> >
> > throw new XmlBlasterException(glob,
> > ErrorCode.USER_UPDATE_ERROR, ME,
> > "Local Callback of " + msgArr.length +
> > " messages to client [" +
> > callbackAddress.getSecretSessionId() + "] failed.",
> > xmlBlasterException);
> > }
> > }
> >
> > What do you say about this?
>
> Yes this was my intention as well.
>
> Marcel
> >
> > //Peter
> >
> > On Mon, 2003-09-15 at 23:58, Marcel Ruff wrote:
> >
> >>Michele Laghi wrote:
> >>
> >>>Hi Peter,
> >>>you'r right. The implementation of the native access has not been
> >>>completed yet.
> >>
> >>I have started on it but hadn't time to finish it.
> >>There are probably one/two days open
> >>for finishing implementation, adding testsuite and docu and a little demo client.
> >>If you do it its fine, otherwise one day i will complete it.
> >>The native access is to be seen in conjunction with the
> >>runlevel manager to load the native client, see
> >>http://www.xmlBlaster.org/xmlBlaster/doc/requirements/engine.runlevel.howto.html
> >>
> >>regards
> >>
> >>Marcel
> >>
> >>PS: The Euro wasn't introduced in Sweden, so my
> >>Kroner lying around somewhere won't be valueless :-)
> >>
> >>>Michele
> >>>
> >>>
> >>>Peter Antman wrote:
> >>>
> >>>
> >>>>Hi,
> >>>>am I right if I have found that client.protocol.local is not working, or
> >>>>should it be able to get it to work (yes, I do have access to
> >>>>engine.Global), but I am getting exceptions on the server callback part
> >>>>(and looking into the code I get the impression that something is
> >>>>missing).
> >>>>
> >>>>//Peter
> >>>
> >>>
> >>>
> >>
> >>--
> >>http://www.xmlBlaster.org
>
>
> --
> http://www.xmlBlaster.org
--
------------------------------------------------------------
Peter Antman Chief Technology Officer, Development
Technology in Media, Box 34105 100 26 Stockholm
WWW: http://www.tim.se WWW: http://www.backsource.org
Email: pra at tim.se
Phone: +46-(0)8-506 381 11 Mobile: +46-(0)704 20 58 11
------------------------------------------------------------