[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] finding out from MsgUnit weather it is publish or subscribe message



On Fri, May 09, 2003 at 11:37:04AM +0200, Michele Laghi wrote:
> Hi Michael,
> the interception of the messages is done by the ClusterManager by 
> invoking the plugins implementing I_MapMsgToMasterId. The problem is 
> that even if you configure more than one plugin, the request is 
> dispatched to only one master (the load balancing mechanism).
> 

Ok - I started looking at the MsgSecurityInterceptor, and it seems for
the very short term, I would be able to intercept publish, subscribe,
and get there to implement my protocol. I believe implementing this in
the cluster plugins would be a cleaner solution though, so I'll do
that as soon as the problem mentioned above is solved.

> Marcel and I will try to sketch an appropriate and generic solution late 
> this evening. One of the critical points is error handling (for example 
> what to do if one of the servers is down). If you have ideas regarding 
> this any comments and suggestions are welcome.
> 
Cool.

I would expect that if one of the servers is down, an error will be
propagated to the cluster plugin to indicate that, and the plugin
programmer can do custom error handling. 

Michael



> For the other thing (isSubscribe, isPublish ...) we could provide a method
> 
> org.xmlBlaster.util.enum.MethodName QosData.getMethod()
> 
> Cheers
> Michele
> 
> 
> Michael Atighetchi wrote:
> >Michele,
> >
> >thanks for pointing this out - you are right: I'd like to do something
> >similar to the "three servers thing with ACK" for publish and query,
> >and I missed the point that the publishfilter can only do publish
> >requests.
> >
> >Looking at the message flow diagram that Marcel put out, it looks as
> >if there are two Cluster plugins. 
> >
> >Can you point me to the Cluster plugin I would use to intercept
> >publish, subscribe, and query requests ? After intercepting, I want to
> >tbe able to send PtP messages to other servers (I figured something
> >similar to XmlBlasterNativeClient), process the responses, and send
> >ptp messages back to the originating client.
> >
> >MIchael
> >
> >
> >On Thu, May 08, 2003 at 08:38:05PM +0200, Michele Laghi wrote:
> >
> >>Hi Michael,
> >>I think we got some missunderstanding here.
> >>The Publish Mime plugin is only invoked when publishing. When you 
> >>subscribe the subscription is never filtered by this plugin.
> >>
> >>Are you implementing the "three servers thing with ACK" here which we 
> >>discussed some days ago ?
> >>If this is the case and if you want the same behaviour for subscribe too 
> >>(as we discussed for publish), then I guess the Publish Mime Plugin is 
> >>not suited for your needs and another approach should be choosen (then I 
> >>think we would need to have a look at the cluster framework).
> >>
> >>Michele
> >>
> >>Michael Atighetchi wrote:
> >>
> >>>Hi Michele
> >>>
> >>>
> >>>
> >>>>You don't use MsgUnits when subscribing so if you have a msgUnit in the 
> >>>>client interface, then it is a publish/publishOneway/publishArray, an 
> >>>>update or the return of a get.
> >>>>
> >>>
> >>>
> >>>I'm actually implementing some code in a publishfilter plugin that
> >>>tries to do certains things if the message is a publish message (and
> >>>other things if it is a subscribe). This is why I'm using
> >>>MsgUnit.getKeyData().
> >>>
> >>>
> >>>
> >>>>>I noticed that KeyData has .isQuery, but no .isPublish or .isSubscribe
> >>>>>? Would it be hard to add these in ?
> >>>>>
> >>>>
> >>>>if isQuery is true then the KeyData object is a QueryKeyData which is 
> >>>>used in erase, get, unSubscribe and subscribe.
> >>>>
> >>>>If isQuery is false, then it is a MsgKeyData which is used in publish, 
> >>>>update and in the return value in get.
> >>>>
> >>>>If you need a finer division than query/Message then we could add the 
> >>>>methods you suggested (or a String getType() method returning "publish" 
> >>>>...). But are you really working directly with KeyData ? in the 
> >>>>org.xmlBlaster.client.key package there are a set of decorators which 
> >>>>should be used instead.
> >>>>
> >>>
> >>>
> >>>I really need a finer granularity (either it is definitly a publish or
> >>>definitely a subscribe). Either a getType implementation or
> >>>.isSubscribe and .isPublish would be fine.
> >>>
> >>>Michael
> >>>
> >>>
> >>
> >>
> >
> 
> 

-- 
matighet at bbn.com   BBN Technologies