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

[Christian Campo <christian.campo@xxxxxxxxxxxx>]

Scott Lewis schrieb:
> 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.
I think that is a big difference between ECF and communication that we do. We don't
have mechanism to recover without user interaction if only half of a HTTP request is
sent. Also that nearly never happens since we work connectionless. So we are creating
a connection for each and every request.
We done extensive performance testing on Hessian and the whole application environment.
We used several professional performance tools that can simulate the random but scripted behaviour of several
thousand users in parallel. So we feel quit comfortable that Hessian will not be a performance
issue and performs very well.
We published a number of articles on Client Server applications and Hessian in specific in a german
 publication "Java Magazine" and just recently in the current issue a description of our performance studies.
> > > > > 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 :).
I look forward to the face to face.... :-)
> Thanks again.
>
> Scott
christian