Heavily multithreaded app

[baptiste]

Hi,

I work on an project which consists of thick Swing clients remotely accessing a data server (probably an app server + SLSB + Spring/Hibernate) and a calculation server. This calculation server has a lot of complicated tasks to do (resource allocation, scheduling...) and will certainly be heavily multithreaded.

I wonder which is the more appropriate technical choice to implement this server. Ideally I'd like to integrate it into the data server, but I'm afraid multithreading inside an app server would cause serious problems. At the other end of the spectrum is plain RMI, which would leave many low-levels issues to the developper.

I'd like to leverage lightweight solutions (Spring, Hibernate...). I consider dumping the app server and go for Spring/Hibernate behind Tomcat (the clients will be javawebstarted). Do you think this solution gives me the flexibiliy I need in terms of multithreading?

BTW, I don't yet understand how Spring relates to multithreading. Is there a good entry point (doc chapter, forum post...) about it?

Thanks for your answers.
Baptiste

[ojolly]

If I had to design an application like this (heavy computation and heavy multithreading with a layer of thick client), I'd go for an app server, eventually a tomcat if you want web as entry point of your thick client, but it could be an app server made of a single java "main' which could chat with the client using hession,burlap or httpInvoker (forget RMI if you can). This app server would handle the multi threading (ell, in the case of a single "main', the jdk alone is involved) and I'd look on the side of clustering to allow higher parallelism.
Tomcat offers it with an apache instance in front of it for example (with session affinity and such) and then you only have to think about the concurency of the db access (but hibernate comes with a jboss cluster cache of 2nd level (usable OUTSIDE jboss app server) ) to allow full clustering and support heavy load.
As for multithreading in Spring, afaik there's nothing special added.
I'm curious, but what projet is this related to, if not confidential ?

HTH

Olivier

[baptiste]

(sorry english spokers, french dialogue ahead)

Merci Olivier le toulousain!
Je bosse pour Alcatel Space (projet type centre de mission). J'ai pas encore tout compris à Spring: peut-on "springifier" une bête appli Java? Si oui, à quel moment les beans déclarés sont-ils instanciés?

Baptiste

[ojolly]

<french>
pour ce qui est des betes appli java, spring fonctionne a merveille. Je n'ai pas trop le temps de repondre en general mais sinon il faut savoir qu'en stand alone, tu cree manuellement un ApplicationContext avec un new, c'est a ce moment que l'instanciation se fait.
</french>

Olivier

[wpoitras]

Spring doesn't really give you much in terms of multithreading. It relies on the various application servers and servlet containers to give you an execution environment.

Spring can help you create your data access and the services for your calculation services. And whatever remoting strategy you decide to use (Hessian, Burlap to a servlet container, RMI for an RMI server, EJB for an EJB server) Spring can simply that as well.

I'm not sure what you mean by heavily multi-threaded on the calculation server. Are you going to use asynchronous processing to help service your requests? Or are you just going to expose a remote service object and have each request be serviced by the thread which dispatched it (which is how normal remote calls work)

[jwray]

Baptiste,

I'm also working on such a system right now. I already had a web application running on jetty using spring, hibernate and tapestry. I had to develop a swing app that would also front this (as a data server) and also add a calculation server, that performs complex operations on the data retreived from the data server.

I'm using spring http invoker as the remote interface of the service layer in my exisiting web app as my data layer. Works really well with minimal extra coding. (I didn't see the need to introduce session beans). In fact, I just added the specification of the remote http invoker into the spring app context files and that was it - a remote service interface. I was very happy that day - my use of spring paid off big time there (the need for a remote interface was never thought of when the web project started).

The calculation server is another matter. Initially I coded up the server also with a remote interface using spring remoting. This works, but provides no load balancing, which is important for me. I really don't want multiple clients all running expensive algorithms on one machine, when we have a cluster of compute machines available. Of course there's solutions using a load balancer and clustered app servers, but I went another direction. I threw together a proof of concept solution using JINI and JavaSpace technology last week, implementing a pattern they (the space developers) call a compute server. Work's very well, providing (by the nature of the solution) load balancing across however many machines in the compute cluster. In theory you can also use the approach to parallelise the underlying algorithm and cluster that. I'm going to be looking into that for a couple of the services I'm providing. So far, I'm actually very impressed with the capabilities of jini, and wish it has a lower barrier to entry. www.jini.org has a lot of background.

Just to be complete, I'm also utilizing spring rcp for the swing front end, which also proving very useful, even in it's alpha stage.

Jonny

Hi,

I work on an project which consists of thick Swing clients remotely accessing a data server (probably an app server + SLSB + Spring/Hibernate) and a calculation server. This calculation server has a lot of complicated tasks to do (resource allocation, scheduling...) and will certainly be heavily multithreaded.

I wonder which is the more appropriate technical choice to implement this server. Ideally I'd like to integrate it into the data server, but I'm afraid multithreading inside an app server would cause serious problems. At the other end of the spectrum is plain RMI, which would leave many low-levels issues to the developper.

I'd like to leverage lightweight solutions (Spring, Hibernate...). I consider dumping the app server and go for Spring/Hibernate behind Tomcat (the clients will be javawebstarted). Do you think this solution gives me the flexibiliy I need in terms of multithreading?

BTW, I don't yet understand how Spring relates to multithreading. Is there a good entry point (doc chapter, forum post...) about it?

Thanks for your answers.
Baptiste

[gershond]

Baptiste,

... Of course there's solutions using a load balancer and clustered app servers, but I went another direction. I threw together a proof of concept solution using JINI and JavaSpace technology last week, implementing a pattern they (the space developers) call a compute server. Work's very well, providing (by the nature of the solution) load balancing across however many machines in the compute cluster. In theory you can also use the approach to parallelise the underlying algorithm and cluster that. I'm going to be looking into that for a couple of the services I'm providing. So far, I'm actually very impressed with the capabilities of jini, and wish it has a lower barrier to entry. www.jini.org has a lot of background.

Hi Jonny,

GigaSpaces, collaboratively with the Interface21 team, have added a Spring-JavaSpaces (and Spring-GigaSpaces extension) support.

The current GigaSpaces-Spring support provides the following capabilities:
=================================================
* GigaSpacesTemplate

* GigaSpaces DAO Support

* Spring Platform Transaction support - Jini (distributed) and GigaSpaces (local TX manager) TX support. Support both declarative (implicit) and programmatic (explicit) transactions.

* Spring based Pojo2Entry converter - provides a declarative way to transform a plain java object into the JavaSpaces Entry format. Dynamic satisfaction of Entry interface for POJO based upon POJO annotation.

* Sync Remoting support (Remote invocation of space objects)

This support is still not publicly available, but we plan on announcing its beta version soon in the J1 conference.

Stay tuned,
Gershon Diner
GigaSpaces Technologies
WRITE ONCE SCALE ANYWHERE