Expert opinion on a huge Turbine app

[Dave Bryson <da...@miceda-data.com>]

Hey all,

I'm involved in a large project to port an existing app that's
currently running on mainframes/Cobal to a J2EE webapp.

I of course want to sell Turbine for use on the frontend (EJBs are on the
backend).  

This project is in the initial stages and has had some consulting
done by a large bluechip company (can you guess who?).   Since I'm the new
guy on the project, I want to tread lightly and have all the answers before
I try to shove a change to the front-end framework.

As I've said this project is *HUGE* ( for example over 1900 views and heavy DB
interaction ) and needs to scale. I've used Turbine successfully on many
mid-sized projects but am curious if it'll have any problems scaling to an app
this size.  My main concern initially is with the singletons (screens and
actions loader).  But I feel the shouldn't be a problem with load-balancing and
replication among application servers ( BTW they're using WebSphere...ugh ).

Does anyone have any experience/thoughts/forseeable problems with Turbine
scaling to an app this size?

Initially it'd be with JSP as the views (Velocity will be the next
selling point...baby steps ).

If I can sell this, it could be a another big step forward for Turbine in terms
of commercial use.         

Any thoughts appreciated!
-- 
Dave Bryson
daveb@miceda-data.com
----------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

Re: Expert opinion on a huge Turbine app

[Daniel Rall <dl...@finemaltcoding.com>]

Dave Bryson <da...@miceda-data.com> writes:

> I'm involved in a large project to port an existing app that's
> currently running on mainframes/Cobal to a J2EE webapp.
> 
> I of course want to sell Turbine for use on the frontend (EJBs are on the
> backend).  
> 
> This project is in the initial stages and has had some consulting
> done by a large bluechip company (can you guess who?).   Since I'm the new
> guy on the project, I want to tread lightly and have all the answers before
> I try to shove a change to the front-end framework.
> 
> As I've said this project is *HUGE* ( for example over 1900 views and heavy DB
> interaction ) and needs to scale. I've used Turbine successfully on many
> mid-sized projects but am curious if it'll have any problems scaling to an app
> this size.  My main concern initially is with the singletons (screens and
> actions loader).  But I feel the shouldn't be a problem with load-balancing and
> replication among application servers ( BTW they're using WebSphere...ugh ).

As the singletons shouldn't be using instance data, internal
synchronization of services and broker would be your main worry
there.  (Unsure about Actions.)

> Does anyone have any experience/thoughts/forseeable problems with Turbine
> scaling to an app this size?

Using the Peer system on large Tigris deployments has been best
facilitated via a cross-host per-JVM in-memory caching system (using
BufferCache), which currently polls the database for cache
invalidation events.  Previously, we had a RMI event notification
system, but the buggy RMI registry kept crashing.  Peer OM object
creation can be taxing on the database, and creating them costs CPU
cycles; keeping them around in memory does a decent job of addressing
this.  Leandro spoke of a generic system--generated via Torque--for
handling this issue today on IRC (share.whichever.com:6667,
#turbine).  So there's one example for ya.  :)

Daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org