synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Abeyruwan <>
Subject Synapse-IRC-Chat Log 05-Jan-2006
Date Thu, 05 Jan 2006 14:16:38 GMT
* Now talking on #apache-synapse
* #apache-synapse :[freenode-info] if you need to send private messages,
please register:
* pvikas (n=p_vikas@ has joined #apache-synapse
pvikas hi all
paulfremantle hi
saminda Hi Paul
saminda Hi Vikas
pvikas hi
saminda Happy new year!
* gdaniels ( has joined
saminda Hi Glen
gdaniels good morning, folks
* Hariharasudhan (n=hari@ has joined #apache-synapse
pvikas so, will we be releasing sometime next week??
Hariharasudhan hi happy new year to all :)
gdaniels We got any perf tests set up yet to check throughput?
saminda we will be, right after Axis2 -0.94 release :)
saminda I'm working on it Glen
paulfremantle hi everyone
pvikas saminda is doing a good job keeping up with axis2 changes.
paulfremantle :)
gdaniels rockin'
gdaniels would be great to get that together soon so we can track the
changes as Axis and Synapse both evolve.
gdaniels Hopefully we watch the throughput go way up and the latency go way
down :)
paulfremantle yep
pvikas amen
pvikas so whats today's agenda?
paulfremantle failover?
pvikas yup
saminda ok
gdaniels So that means we should all also join #apache-synapse-backup on
another server network just in case? :)
saminda :)
paulfremantle hehe
pvikas and this should be entirely independent, don't ask synapse to route u
saminda We could introduce a new Processor
pvikas thats an extension...
gdaniels Um, refresh my memory here - Processor == Mediator, or is that
something else?
saminda or we can call a Mediator through <sendmediator/>
gdaniels oh it's something else then
pvikas failover is a service, not a extension
pvikas people might have different notions of failover, they just plug in
their mediator, a processor would be too much..
saminda We can do Mediation writing a *Meditor* or writing a *Processor*
first one is API level second one is SPI level
pvikas API is simple, straight
pvikas Procesors can do everything that synapse needs, they are all
powerful, but lets not dump everything in there
paulfremantle vikas.... is failover built in? i would say so
saminda API is user level SPI is Advance level :)
gdaniels failover permeates pretty much everything....
Hariharasudhan paul .. why not ??
gdaniels including EPR generation/interpretation, for example
pvikas it can be looked at as an standard mediator we would provide..
saminda now if it has to be built in it should be a Processor
paulfremantle soooooo
paulfremantle this brings up an interesting question
saminda Processor vS Mediator i wonder
pvikas a fine line between processors and mediators..
paulfremantle do we need the divide between mediators and processors
paulfremantle ant elder suggested not
paulfremantle in effect we could unify them
paulfremantle and there would be two things:
saminda we don't need to divide a fine line between them
paulfremantle a Mediator (runtime)
pvikas well, correct me if i am wrong, Processors = logic to call mediators
and do evaluations in the synapse.xml
pvikas mediator = services
paulfremantle and an xml.MediatorFactory
paulfremantle which would read the XML and produce a mediator
saminda Processor.process() pretty much can do everything
paulfremantle so if we refactored that way, then you can either use the
standard <mediator> tag to config a standard mediator
paulfremantle or create a custom mediatorfactory that can read the XML
saminda ex: look at ServiceMediatorProcessor, LogProcessor etc
paulfremantle I wasn't convinced at the time Ant suggested this
paulfremantle but I could be persuaded if it makes it simpler
gdaniels Paul: So (not to jinx this idea or anything) you're basically
talking about one rule :: one Mediator, in a way, right?
pvikas lets not blur the distinctions we have now, they look all fine and
paulfremantle glen I dont understand yr question
gdaniels Then the Mediator (or MediatorFactory?) processes the "sub rules"
Hariharasudhan yes
gdaniels maybe I'm not understanding the suggestion, tho
paulfremantle im not suggesting a change to the synapse.xml or to the
paulfremantle the only suggestion is that there is mediator.mediate(SM) and
processor.process(SE, SM)
paulfremantle which are fairly similar
paulfremantle (at runtime)
paulfremantle so Ant asked me why we needed both... and I said... we need a
distinction between extensions (SPI)  and mediators (API)
pvikas lets look at the logical differences between a processor and a
saminda Paul if we use mediator.mediat(SM) that will lose flexiblity
saminda for ex: our SynapseEnvironemt  is a context
paulfremantle Saminda --- well Ant also suggested adding
getSynapseEnvironment to the message
paulfremantle to solve that
paulfremantle its a shame he's not online....
saminda which is the only one that exist in all time in Synapse Environement
saminda we can keep some globle level properites there
paulfremantle yes +1 saminda
saminda we lose that if we use the first one med.mediator(SM)
saminda getSynapeMessageEnvironment() is added
paulfremantle not if we add SynapseMessage.getSynapseEnvironment()
saminda we can remove EnvironmentAware
paulfremantle yes
saminda and we have a context hiearachy
saminda SynapeEnvironment 1---* SynapseMesssage
paulfremantle ok... but that may be useful if for example we are supporting
pvikas guys, we still haven't addressed what should be a processor/mediator
or wether we need 2 separate things at all...
paulfremantle good point vikas
saminda mate we need Mediators as well as Processors
saminda it depends on how you look at the Problem space
paulfremantle i'm not convinced so convince me :-)
pvikas but then since processors can do everything that mediators do, we'll
always be at cross roads...
paulfremantle we need both standard and custom XML
paulfremantle we also need a way to extend the system (plugins)
paulfremantle but I'm not sure we need both procs and meds
saminda Mediator is the only link to Axis2 Service or Service Group
saminda that the only thing that sperate a regular service from a Mediator
gdaniels Paul: You can extend the system in lots of ways though... by
inserting things in the standard processing chain, by adding new context
types, etc. etc.  There isn't just a single plugin arch.
paulfremantle we can still have service mediators
paulfremantle i agree glen
paulfremantle i just dont know if we need two runtime artefacts that are so
gdaniels so I think the thing we need to decide is - how do messages get to
processing components (putting aside Mediators vs. Processors at the moment)
saminda But i see a different between them
paulfremantle anyway it wasn't my idea.... i just threw it out because we
seemed to be arguing about whether things should be processors or mediators
paulfremantle glen i don't understand that point
gdaniels in other words - what does the CORE Synapse system let you do with
respect to routing/dispatch and basic "rules" (i.e. only URL based dispatch,
for instance)
gdaniels and what do custom components (i.e. XPathThingy) let you do
paulfremantle if I understand you correctly - you are saying we first need
to decide what is core to synapse and what is an extension
gdaniels There are two potential levels of dispatch - the system level,
which can be dead-simple, and then the custom level, which exposes the APIs
for "send this to component 'foo'" and allows components to build their own
rules and decision making logic
paulfremantle i think thats a hard question because one persons extension is
another persons core
gdaniels Paul: right, and of course there are a lot of "extensions" that are
really core
gdaniels s/core/included/
paulfremantle yes
gdaniels I'm just talking architecturally
paulfremantle so architecturally we don't have that split anymore really
saminda yes
gdaniels really?  don't you have to bootstrap?
paulfremantle we just process messages.... we have a single model (which I
think you argued for Glen).
paulfremantle each processor can call other processors
gdaniels how does the first processor get called?
saminda there is a MasterProcessor
gdaniels or is there just one?
gdaniels ah
paulfremantle sure you read the XML and create a master processor =
paulfremantle that one usually calls other ones
gdaniels ok
saminda so masterprocessor is bootstrap isnt it
gdaniels so there's a distinction between Processors and Mediators... what's
that about?
saminda that the buty i see in this architecture
saminda Mediators can be invoked through processor
gdaniels a Processor processes a Message - doesn't a Mediator do the same?
saminda ex: <servicemediator/> corresponding to ServiceMediatorProcessor is
the one that call for Axis2 service
saminda Mediators are Axis2 services
saminda they can't be directly put to synapse.xml
saminda only with co-existing processor like <servicemediator/>
gdaniels why not?
gdaniels I mean, we certainly could have Synapse auto-deploy stuff to Axis2
for us
paulfremantle also not all mediators are Axis2 services
saminda yes
paulfremantle and in fact I think that is a sub-optimal model
saminda <classmediator/> for instance
gdaniels what is a sub-optimal model, Paul?
paulfremantle i think its easier to use the classmediator because you can
have all the config in one place
paulfremantle deploying mediators as axis2 services
paulfremantle glen
gdaniels so if mediators are NOT Axis2 services, how do we associate QoS
with them?
saminda what if we dont' want to associate qos and
saminda make the faster path faster
saminda and simple
paulfremantle so glen
paulfremantle the way we have done that
gdaniels I'm asking when we DO want to associate QoS, not when we don't. :)
paulfremantle is to have an empty mediator
paulfremantle and run through axis
paulfremantle call the empty message receiver (which does nothing)
paulfremantle and associate the QoS with that AxisEngine instance
saminda this is for treate addressing as qos
paulfremantle in fact I got the idea from you at the F2F when you told me
how easy it is to instantiate a new AxisEngine
paulfremantle but it works for any Axis2 module as well as addressing
saminda yes i got your point Paul
gdaniels so how do we deal with RM - Axis might need to pause a message
because it's out of order - will Synapse correctly pause as well?
paulfremantle ah I posted an approach for that one :-)
paulfremantle on the mailing list
gdaniels ok - sorry haven't read it yet!
saminda that one situation Glen we have to delt with
paulfremantle by the way that is a problem whichever approach you take for
paulfremantle my suggestion was a simple first take
saminda Paul's suggestion on RMProcessor is practical
paulfremantle which is that there is a special message receiver for that
which re-inserts messages into synapse
paulfremantle so that there are in effect two synapse flows
paulfremantle first flow up until the pause
paulfremantle second flow starting from the inorder message being reinserted
paulfremantle and you have to write a set of rules that makes sure the right
processing happens to each flow (the hard bit)
saminda yep
paulfremantle its not perfect but its a simple starting point
saminda trust me giving Security as QoS is much more simple :)
* pvikas_ (n=p_vikas@ has joined #apache-synapse
saminda once they broken down it to sperate units like "encrypiton", etc etc

pvikas_ I think i missed a lot
* pvikas has quit (Read error: 110 (Connection timed out))
* Hariharasudhan has quit (Read error: 113 (No route to host))
saminda Paul are we gonna give RM as you mentioned in M1
paulfremantle I would say probably not
paulfremantle unless someone can do it quickly :p
saminda oh
saminda M2
paulfremantle glen you've gone quiet
gdaniels hm
paulfremantle did you grok my explanation?
saminda If i summerize, the state of Synapse can route messges between
different transports (ex: http--tcp)
gdaniels (was afk for a min - just read your stuff, thinking)
* Hariharasudhan (n=hari@ has joined #apache-synapse
saminda Paul a question regarding Rm
Hariharasudhan sorry we had a network problem
gdaniels so it seems there might even be other reasons to pause a synapse
flow aside from RM - load balancing, event processing systems, etc...
gdaniels maybe what's needed is a good generic system for allowing
components to pause and restart, like Axis has
pvikas_ event processing as in Instrumentation??
paulfremantle i guess so glen.... but there is a lot of code in Axis for
saminda Axis2 has
paulfremantle and I wanted to try to re-use to for starters
paulfremantle and only add it if we needed it
paulfremantle thats why i suggested a simple starter for RM
gdaniels it's just a matter of keeping some state, but sure reuse is good
saminda "Zero Traning" :)
gdaniels if we're using Axis anyway all we should need is a pointer to a
SynapseContext in the MessageContext and some Handler somewhere that knows
how to call back to Synapse and say "run the next thing"
gdaniels that's the key difference though - you have to let the chaining
happen as a result of going down into Axis instead of running the "loop"
yourself, to some extent
gdaniels need to think about this more
paulfremantle the problem with that
pvikas_ RM is going to be a module right?
paulfremantle each processor
paulfremantle needs to have the logic
saminda yes
paulfremantle to save the "what the next thing"
paulfremantle which is a big change
gdaniels that's a worthwhile change, I think
gdaniels if we do it right
gdaniels we're gonna want that anyway for failover (and poof, we're back at
the original topic!!)
paulfremantle why do you pause for failover?
saminda yes, i am wondering why
gdaniels it's not so much pausing as saving your state across a cluster so
you can pick up elsewhere on failure
gdaniels but it's the same idea of save-state-and-execution-pointer
pvikas_ yup
gdaniels you don't necessarily have to do it that way - if there are no
side-effects to processing (or they are always rolled back), you can just
start at the beginning for each failed-over message
gdaniels but if there are side-effects or complex processing you might want
to be able to restart in the middle
saminda we can do that with current context
saminda yes, that's one way to look at it :)
paulfremantle i would much prefer the rollback model
gdaniels woop - I gotta head to the office, folks... I promise to catch up
on the mailing list and comment appropriately (new year's resolution ;)).
pvikas_ c ya glen
paulfremantle i see synapse as a stateless high-performance processor
saminda i like it too Paul
paulfremantle bye glen
gdaniels TTY later, Synapsians!
saminda bye glen, it's nice to have you here today
* gdaniels has quit ()
pvikas_ after a long time
saminda Synapsians! thats cool
pvikas_ so did anything about the line between processors/mediators get
saminda Paul, Glen has a point we need to discuss it
saminda Mediators are API level and Processors are SPI level
saminda Advance mediator writes always welcome to use Processors to the
mediaton work
saminda like the way Axis2 Client wirting being seperate
pvikas_ lets just chalk up some distinctions.. don't want the divide to be
saminda Api users has ServiceClient
saminda Spi users has to deal with OperationClient,
pvikas_ will try both procesor and mediator model and let ya ppl know..
saminda Guys what do you think of the current Synapse code base state
paulfremantle so saminda
pvikas_ quite good
paulfremantle the division could be
paulfremantle API = mediator
paulfremantle SPI = xml reader & custom mediator factory
paulfremantle that still fits
saminda that's what my mind set always has been fixed, +1 Paul
paulfremantle i have to go in a minute
saminda current synapse state guys !!
paulfremantle good
saminda may be tomorrow we have Axis2-0.94
pvikas_ hope so
saminda Glen has given us some points to think aloud,
pvikas_ who is posting the log??
saminda i got the stuff
saminda are we there yet!!
paulfremantle yes please post the log.... i think we are ready for a M1
saminda Cool
saminda oh REST--->SOAP test case coming tomorrow
pvikas_ ya.. we can divide and fine grain failover, pauses, processors,
mediators as we go on!
saminda will put the pref test result asap
paulfremantle thanks saminda
pvikas_ thanks u..
* paulfremantle ( has left
pvikas_ so will this be all for today's chat?? [ eagerly looking forward to
the log]
pvikas_ bye saminda
saminda bye guys!
* pvikas_ has quit ("ChatZilla 0.9.61 [Mozilla rv:1.7.2/20040803]")

View raw message