10 Replies Latest reply on Oct 2, 2011 10:39 AM by asookazian

    Seam 3 and SFSBs

    asookazian

      is Seam 3 advocating the usage of SFSBs as the backing beans for JSF components?  If you have a very large, high-volume site like eBay, you'd need servers with tons of RAM to handle tons of SFSBs (one SFSB per client) as well as the state replication overhead from node to node in a cluster.


      Is this an issue or not?  I would imagine stateful components (which may live in RAM for dozens of minutes potentially) are not as attractive or am I wrong? 

        • 1. Re: Seam 3 and SFSBs
          piklos

          Honestly, i think that most people that want to achieve stellar volumes wouldn't want to use JSF or EJB at all.

          • 2. Re: Seam 3 and SFSBs
            lightguard

            No, we're not advocating SFSB. If they make sense for your application, great, use them, if not, you don't have to use them.

            • 3. Re: Seam 3 and SFSBs
              asookazian

              miklos piklos wrote on Sep 29, 2011 19:19:


              Honestly, i think that most people that want to achieve stellar volumes wouldn't want to use JSF or EJB at all.


              good answer, i agree.  so what is the Java EE 6 recommendation for a high-volume app like eBay.  Don't say Spring/SpringMVC/Hibernate/Oracle/etc.  I'm asking specifically Java EE 6 and the JSRs in that spec (so not GWT, etc.).  thx.


              I hoped that Seam graduated to high-volume apps by now...

              • 4. Re: Seam 3 and SFSBs
                pgmjsd

                Jason is right.  Use what works for you.


                For example, SFSBs without cluster replication works well for our application.   We have a relatively small number of users who want nearly real-time updates and it pays for us to have (somewhat large) in-memory state for each user.


                If you have lots of users and less state, then maybe SFSBs with replication works.


                If you have lots of users, and almost no state at all, then SLSBs work well.



                miklos piklos wrote on Sep 29, 2011 19:19:

                Honestly, i think that most people that want to achieve stellar volumes wouldn't want to use JSF or EJB at all.

                Most people have delusions of grandeur.  These delusions cause them to build their own state management on top of 'shared nothing' or other 'lightweight' (and heavily hyped) architectures.   With JE6 you can chose how stateful / stateless you want to be for each part of your app.   JE6 can be as light as many lightweight frameworks, but only if you bother to learn about it. ;)


                • 5. Re: Seam 3 and SFSBs
                  pgmjsd

                  Arbi Sookazian wrote on Sep 29, 2011 18:35:

                  Is this an issue or not?  I would imagine stateful components (which may live in RAM for dozens of minutes potentially) are not as attractive or am I wrong? 


                  As I said, our Seam app has certain parts that are highly stateful.   Our users will log in once in the morning and the components will stay in memory all day without issues.   It's kind of a special case though, as our user base is relatively small and we control it's growth.


                  If you have an unconstrained number of users, then obviously this is something you need to think about.   You can use SFSB passivation, conversation and session timeouts to 'page out' dormant session state.


                  In any case, I think SFSBs have a bad reputation, and this is unfortunate.   Maybe it's because many system designers have had so much trouble with clustered HTTPSessions?

                  • 6. Re: Seam 3 and SFSBs
                    lightguard

                    Good stuff Joshua. Too many developers and architects want a magic button/wand/framework/solution that will solve the state and high volume problem. It isn't going to happen. Everyone has to think about their application, users, criteria and make the best decisions for themselves.


                    If you want something very scalable as far as memory usages goes, use a stateless architecture and use REST on the backend. Of course then you have CPU and bandwidth issues because you have to send more across between the server and the client. If you want to keep state on the server, be prepared to use a lot of memory and machines, and have a good caching mechanism in place. There's trade offs wherever you go, you and your team have to figure out what works best for your needs.

                    • 7. Re: Seam 3 and SFSBs
                      piklos


                      Most people have delusions of grandeur.  These delusions cause them to build their own state management on top of 'shared nothing' or other 'lightweight' (and heavily hyped) architectures.   With JE6 you can chose how stateful / stateless you want to be for each part of your app.   JE6 can be as light as many lightweight frameworks, but only if you bother to learn about it. ;)



                      But seriously are there any web sites that use JSF (let alone SFSB) and have volumes somewhere about tens of millions of requests per day? None that i could find.Why is that so?

                      • 8. Re: Seam 3 and SFSBs
                        pgmjsd

                        miklos piklos wrote on Oct 02, 2011 05:25:


                        But seriously are there any web sites that use JSF (let alone SFSB) and have volumes somewhere about tens of millions of requests per day? None that i could find.Why is that so?


                        The application my company makes handles 5 to 8 million HTTP requests a day.   Most of them are AJAX calls to an EJB3 SFSB via Seam Remoting (Seam 2) from a JSF generated web page.  So, it works for us.   The most important thing is, does the framework you are using work for your requirements.

                        • 9. Re: Seam 3 and SFSBs
                          asookazian

                          Joshua Davis wrote on Oct 02, 2011 08:52:

                          The most important thing is, does the framework you are using work for your requirements.



                          that's correct.  and in the vast majority of cases for Seam 2.x, I'd say no due to the performance and potential scalability concerns (e.g. async/sync state replication in JBoss cluster for SFSB state as backing beans).


                          I've heard multiple ppl complain about this and the answer is upgrade to Seam 3 which fixes the problem via CDI/Weld.


                          I'd really like to know whether or not the expert groups and JCP actually write various POC apps for EE X impls and test them out for various non-functional requirements.  Never heard about that.  TCK is different...

                          • 10. Re: Seam 3 and SFSBs
                            asookazian

                            In any event, I hope one day I will again work on a Seam app.  I kinda miss it.  Spring/Hibernate is so prevalent esp. in older systems.  And it's difficult to justify going from Spring 2.x to EE 6/Seam3 when you can get similar APIs/upgrade to Spring 3.x.


                            Anyways, the mobile and cloud space is really where it's at but there will always be enterprise and back-office apps as well.


                            I also wonder how the Ceylon and Seam 3/4 integration will be?