Announcement Announcement Module
Collapse
No announcement yet.
Standalone multithreadedserver based on Spring IoC Container Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Standalone multithreadedserver based on Spring IoC Container

    Hi,

    I am looking into a standlone server based on Spring container.

    It is NOT a request/response based server.

    Say the example server is a chat server where clients create sessions.
    The server listens for requests and creates sessions on client requests.
    Each session has to listen for message and distribute to other clients in the session.

    This server requires each chat session to run in is dedicated thread (or runnable) and many sessions will potentially co-exist.

    The big question is how to make the server multithreaded using Spring.

    Anybody have any ideas how to accomplish this using Spring?

    /Morten

  • #2
    I am looking into a standlone server based on Spring container. It is NOT a request/response based server.
    So you are going for bi-directional communication?


    The big question is how to make the server multithreaded using Spring.
    In my opinion Spring does not add additional requirements here. Normally you just add another worker thread(s) to do the actual work and here you go.

    The only thing that remains interesting, I guess, is how the clients and the server (or better the nodes) interact and communicate. But this is a question of choosing between uni-directional communication (e.g. polling) to simulate bi-directional communication or true bi-directional communication (e.g. sockets, message driven approaches, ...). But this is also not a choice related to Spring in my opinion.


    This server requires each chat session to run in is dedicated thread (or runnable) and many sessions will potentially co-exist.
    It is questionable that each session really needs to run in a dedicated thread. It is one solution, but I am not sure, if it is the only good solution. At the end the choosen way of communication might dictate another solution (for example, one thread per client). But it depends on your requirements.

    The way you implement your server normally only depends on your application's requirements. Luckily Spring gives you great freedom here. But freedom is also a burden - the choice is on you.

    To tell you something, that my serve you better than 'the choice is on yours' I would like to have more informations. What are you planning to do and where is the actual point, that makes you worried.


    Cheers,

    Martin (Kersten)

    Comment


    • #3
      Hi,

      the issue is that all example usage of Spring is for request/response type of services.

      Take the chat server as an example. A "chat session"/ or controller is create on first request. It controls all messaging with initiator and also with other clients entering the session.
      This controller needs to maintain state, a thought was to provide multitasking/multithreading to enable multiple simultaneously requests.

      Another example could be an IM server/Jabber server.
      The server starts socket listeners for incoming messages. I believe this has to be in a separate thread.

      The socket listener receives the packages and passes then on to session controllers...

      How may SPring be used here without support for multithreading.

      One also needs to be able to conduct load control. To limit number of requests and cut off in case of "overload".

      Spring seems to just take all the requests it can until the server is overloaded/congestied.

      My initial thought was to add multithreading/threadpools to bean proxies/factories.... on incoming request a new task is created and put in the threadpool. A task in this respect just calls the bean it is wired to call.

      The point is that it would be possible to limit requests to the server.
      The app config configures a threadpool.

      The whole issue is how to base a server on Spring, and not just use it in a webapp for request/response stateless service.


      Hope you can suggest how Spring can be used to architect such a system with protocol listeners and controllers(perhaps using statemachines) sending and listening to several protocols....

      /Morten

      Comment


      • #4
        My initial thought was to add multithreading/threadpools to bean proxies/factories.... on incoming request a new task is created and put in the threadpool. A task in this respect just calls the bean it is wired to call.

        The point is that it would be possible to limit requests to the server.
        The app config configures a threadpool.
        I would see "the limiting of active connections/clients" as a functional requirement of the application. So if we make up an illustrational use-case, this functional requirement will appear as a part of the business process. Since this part of the business process can be seen as being exceptional, it would most likely be modeled as a business exception. So I wouldn't deal with this by using an implicit solution.


        The whole issue is how to base a server on Spring, and not just use it in a webapp for request/response stateless service.
        The most important thing is the start-up behaviour of the server, I guess. First of all you need listeners (as you already stated out). A socket listener for instance, is just started in the initial phase of the server. All you need to do is to create a factory bean, add the required logic to create such a socket listener and here you go. I would think such a bean as being specified as a singleton, which is not lazily initialized (lazy-init="false").

        The rest is up to you. Just set up and install your communication listeners and the rest is normal application stuff beyond Spring (I guess). Just model your domain and add connection channels for providing business interfaces. But this isn't Spring related anyways. Spring just helps you to integrate (compose) and to configure applications.


        Cheers,

        Martin (Kersten)

        Comment


        • #5
          Hi,

          Thanks. It takes getting used to what Spring really offers.

          Spring just helps you to integrate (compose) and to configure applications.
          It seems like Spring is merely a framework which, like you say, eases config and offes some UTIL support. Not so much beyond that.

          The actual execution environment is then left to the developer.
          But, if this is so, I cannot understand why Spring is popular... Organizing the objects with config is the easy part and all projects develop for themselves util libs.

          What I am looking for is deeper into the runtime environment which executes the container(Spring) and provides e.g. threadpools etc...

          I guess I can use Spring as a container, but making a standalone server requires to develop and provide the beans need and put it outside the container and use injection...

          With frameworks like Spring it is difficult to see exactly where Spring "stops" and what it offers, and where the developer is on "his own" again.

          The book of Rod Jonson is all about J2EE without EJB and it mentions SPring a lot, but what is missing is really how to architect a standalone server in which Spring is the container.

          The Spring in Action also critizies Avalon for being intrusive, but I guess the avalon container(and excalibur) has come further with respect to runtime environment support?

          Hope to find out more about how to make the standalone server in which Spring is the container because it really does quite a lot... but what it doesn't do is improtant to grasp as well....

          /Morten

          Comment


          • #6
            I guess I can use Spring as a container, but making a standalone server requires to develop and provide the beans need and put it outside the container and use injection...
            You are refering a lot to the term 'standalone server'. I still don't get what exactly this term mean to you. Also I don't know why you consider the needed beans to be put outside of the container. Maybe I misunderstand it but I wouldn't say these beans are outside of your application/container.


            The actual execution environment is then left to the developer.
            But, if this is so, I cannot understand why Spring is popular... Organizing the objects with config is the easy part and all projects develop for themselves util libs.
            Spring is very easy but yet very powerful. Also that the actual execution environment is left to the developer is the biggest advantage in my opinion. The Spring folks have done a very good job on introducing AOP and providing useful abstractation of some of the most often needed components and the documentation was very good from the beginning.

            Also it isn't that difficult to create a bean factory for the socket example. Chose the solution you want to use and create a set-up part and thats all.


            Cheers,

            Martin (Kersten)

            Comment


            • #7
              Standalone server...

              Hi,


              You are refering a lot to the term 'standalone server'. I still don't get what exactly this term mean to you
              Ok, almost all examples, also in the Spring distribution is of webapps. I.e.spring is merely an "object organizer" and the app server(e.g. Tomcat) provides for receiving the request and passing it to business logic.

              In this scneario Spring directly competes with EJB and does not in my opinion stand up to what EJB provides to developers.

              Where I expected Spring to be an asset was in making appservers without beeing needed to plug into other appservers like tomcat... but being able to make a simple appserver which fits into an J2EE architecture.

              If I use e.g. Spring as a container in TOMCAT I have to make a servlet which loads on startup and .... well, perhaps ok... but I do not need Tomcat... but a simple server which can perform dedicated tasks like calculation , DB access, integrate legacy systems etc...

              Anyway, great that you help out with discussing alternatives!!!!!!!!!!

              /Morten

              Comment


              • #8
                It seams that I now understand, what the term 'standalone server' might mean to you. I am used to a quite diffrent meaning. For me a standalone server just forms a single node system. So for me standalone servers are not about to Tomcat or not to Tomcat (no need to get loud by the way). Also I guess architecture is just another term we seam to not agree upon.


                Where I expected Spring to be an asset was in making appservers without beeing needed to plug into other appservers like tomcat... but being able to make a simple appserver which fits into an J2EE architecture.
                What is a J2EE architecture for you?


                Anyway, great that you help out with discussing alternatives!!!!!!!!!!
                It is always a pleasure for me to help you out... .


                Cheers,

                Martin (Kersten)

                PS: Check out the ApplicationContext. Create an ApplicationContext from a xml bean definition file (for instance) and you will have an application. If you add communciation channels to the application and impose interface specifications, then you will have a simple server without the need of an advanced application server like JBoss or Tomcat. (Hopefully this is that you wanted to know, I just remain in guessing-mode... ).

                Comment


                • #9
                  Standalone server ...

                  Hi,

                  J2EE architecture:

                  I guess architecture is just another term we seam to not agree upon.

                  Well, my understanding too many architects mean EJB=J2EE.
                  Also examples in usage of Spring seem to mean EJB = J2EE and that Spring merely helps you out on the tedious bits like config, i18n, and the like ... the remoting with e.g. rmi is nice, but really not difficult to add yourself...

                  With respect to J2EE I guess I most people think of J2EE for web-application, thin clients, perhaps also thick clients.

                  In my J2EE picture the "small servers", like protocol machines also exist. On what appserver platform does one make those?
                  E.g. in the IM/Jabber server case. A traffic server. Terminates a protocol, sends requests to service logic handlers/controllers and perhaps to transporters for S2S traffic.

                  The "traditional" J2EE server may exist for "back office" applications, like customer management, service provisioning etc.

                  But what about the server which actually handles the Jabber protocol?

                  There is an open source project, Open IM, which has used Avalon, now ported to Merlin.
                  Merlin here provides a Container which seems to be more like an execution environment as well as has the "service" concept which may be compared to "beans" concept in Spring.

                  So, when I read about Spring "framework"... it gets a bit confusing when Spring "stops" and leaves the execution environment to "others" ....


                  I think that Spring In Action book says that Spring is not "intrusive" as opposed to e.g. Avalon, but, Spring is equally intrusive as any other container I have seen, like beans becoming "aware" .....

                  So, does Spring really only fit as help for making webapps faster, or EJB's faster ?

                  I have tried the java main with creating the app context, exposing a service as rmi, then consuming it in another application. Really easy to accomplish...
                  But for the "server" part I have absolutely no control on number of simultaneously requests....I can only "hope" that load does not skyrocket....

                  This of course is not a satisfactory set up.... as "resource control" is important for systems which needs to stay up always....


                  Anyway, interesting to find out how Spring really can help out. It is really easy to set up and get running. No problem at all.

                  An interesting bit is the granularity of the "beans". Is that "subsystems", like which receives requests and passes them to real objects(implementors). Or Is all and every object exposed using xml config and getBean....

                  Regardless, interesting it is!

                  Comment


                  • #10
                    Re: Standalone server ...

                    Originally posted by mhaavald
                    Hi,
                    So, when I read about Spring "framework"... it gets a bit confusing when Spring "stops" and leaves the execution environment to "others" ....

                    I think that Spring In Action book says that Spring is not "intrusive" as opposed to e.g. Avalon, but, Spring is equally intrusive as any other container I have seen, like beans becoming "aware" .....
                    These are special beans. My application beans never implement Spring interfaces to become aware of Spring.

                    I have tried the java main with creating the app context, exposing a service as rmi, then consuming it in another application. Really easy to accomplish...
                    But for the "server" part I have absolutely no control on number of simultaneously requests....I can only "hope" that load does not skyrocket....
                    This is a problem of RMI, not Spring. You could add control on the number of connections yourself, rejecting access to services if the number of connections is to high. The RMI connection is made, but the user can`t use the system.

                    An interesting bit is the granularity of the "beans". Is that "subsystems", like which receives requests and passes them to real objects(implementors). Or Is all and every object exposed using xml config and getBean....
                    I never let normal objects have a reference to the application context. All the dependencies are injected via the constructor (or via a setter). My code is not aware of Spring.

                    Comment


                    • #11
                      Re: Standalone server...

                      Originally posted by mhaavald
                      Hi,
                      In this scneario Spring directly competes with EJB and does not in my opinion stand up to what EJB provides to developers.
                      What does EJB give you what Spring doesn`t have? The only thing I can think of is 'truly' distributed applications. But if you save all state in a db, and put a load balancer in front of a few (Springed) servers, this will fit your needs.

                      Comment

                      Working...
                      X