[news.eclipse.technology.riena] Re: Release 1.0.0.M1

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Christian,

Christian Campo wrote:
<stuff deleted>
> > OK.  Just FYI, this extension point/service will be in p2/Ganymede so 
> > there will be no extra cost in distribution/size, etc.
> Not sure about that since Riena apps don't necessarily have the whole 
> IDE in but just
> a selected list of bundles. But I keep my eyes open.


OK.  At least the ECF core bundles (org.eclipse.ecf and 
org.eclipse.ecf.identity including namespace ep) will just be in 
IDE...but every distribution that uses Equinox p2.

> >
<stuff deleted>

> > You might want to also test it with/on clients that have very 
> > slow/unreliable network connections as well.
> Our production system where we use Hessian has clients on:
> LAN, WLAN, Router, ISDN, DSL (multiple speeds), UMTS, GPRS, Sky-DSL, 
> Cable-modem......
>
> So I thought we covered that area mostly...... :-)


OK.  It would be interesting to know happens in terms of responsiveness 
under heavy loads (rapid/multiple/sec invokes of remote methods)...and 
when some clients fail (i.e. network partition in middle of 
request/response).  This isn't a rhetorical question, as for apps that 
have high responsiveness and bw requirements (e.g. IM, voip, rt collab) 
these situations occur frequently.

But I understand that Riena is just getting going, so maybe as things 
get more established if you could just post your test results on a bug 
somewhere as you do them that would be helpful.

> > > > 6) What about multiple simultaneous thread access to a given service 
> > > > method?  How is this handled?
> > > it works.:-).....all objects that are call based are local variables, 
> > > some are stored in ThreadLocals
> >
> >
> > Doesn't the ThreadLocal usage make it difficult to non-blocking calls 
> > (i.e. calls based upon transports other than hessian/http)?
> The ThreadLocals are within the publisher and factories for hessian. So 
> if you
> use another transport than you can choose what you like to use. Also (as 
> discussed
> in earlier threads) we prefer synchron calls and placing them in 
> background threads
> using the jobs api, rather than making a asychronous call. Riena 
> communication only
> does synchron calls since you call a business related method in an 
> interface and expect
> the result to be available when the call returns.


Yeah.  I understand this perspective (synch only).  As you know, I think 
it's somewhat limiting for reliability, scalability, and performance 
(i.e. no reason to block waiting for response when you don't expect/want 
any)...for a variety of distributed applications...but no reason to have 
that discussion over again...at least before EclipseCon :).

Thanks again.

Scott