1 2 3 Previous Next 41 Replies Latest reply on Sep 7, 2011 1:23 PM by wolfc

    SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1

    aravindsk

      i am currently using 6.0 CR1 and implementing using ejb3.1

       

       

      @Startup
      @Singleton

      @Startup

      @Singleton

       

      public class StartupBean {

      String item = "";

       

      @Resource

      TimerService timerService;

       

      @EJB

      SLSBean sBean;

       

       

           @PostConstruct

      public void init() {

       

      timerService.createTimer(1 * 60 * 1000, 1*60* 1000, item);

       

      }

       

      @Timeout

      public void process(javax.ejb.Timer timer) {

       

      try {

      sBean.process(timer);

      } catch (Exception e) {

       

      e.printStackTrace();

      }

      }

      }

       

       

       

      @Stateless

      public class SLSBean {

       

      @Inject

      private Logger logger;

       

       

      @Asynchronous

      public void process(javax.ejb.Timer timer) {}

      }

       

       

      it always shows only one instace of SLSBean is created when i expected multiple slsb's

       

      config:

      Available Count 1

      Create Count 1

      Current Count 1

      Max Size 1 The maximum number of instances that are allowed to be pooled

       

      ejb3-interceptors-aop.xml show max size of  30.

       

            <annotation expr="class(*) AND !class(@org.jboss.ejb3.annotation.Pool)">
               @org.jboss.ejb3.annotation.Pool (value="ThreadlocalPool", maxSize=30, timeout=10000)
            </annotation>

       

      what is that i need to change so that multiple slsbs created and pooled.

       

       

       

       

        • 1. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
          jaikiran

          A new instance of SLSB will only be created when the current SLSB instance is in use in some other invocation. Is that how you are testing this?

          • 2. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
            aravindsk

            thanks for this quick response. in the above process method i implemented a long running logic. just to test if the second timeout event in Startup bean calls second instance of slsb. but it did not.

             

            File tmpdir = new File("/tmp");
            File tmpfile = new File(tmpdir, "security.rar");
            InputStream in = new java.io.FileInputStream(tmpfile);
            BufferedInputStream fin = new BufferedInputStream(in);
            File ofile = new File(tmpdir, "security.rar_"+new Date().getTime());
            OutputStream o = new java.io.FileOutputStream(ofile);
            BufferedOutputStream fout = new BufferedOutputStream(o);
               int i;
               do {
                 i = fin.read();
                 if (i != -1)
                   fout.write(i);
               } while (i != -1);
               fin.close();
               fout.close();

                                   File tmpdir = new File("/tmp");

            File tmpfile = new File(tmpdir, "security.rar");

            InputStream in = new java.io.FileInputStream(tmpfile);

            BufferedInputStream fin = new BufferedInputStream(in);

             

            File ofile = new File(tmpdir, "security.rar_"+new Date().getTime());

            OutputStream o = new java.io.FileOutputStream(ofile);

            BufferedOutputStream fout = new BufferedOutputStream(o);

                int i;

                do {

                  i = fin.read();

                  if (i != -1)

                    fout.write(i);

                } while (i != -1);

                fin.close();

                fout.close();

            • 3. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
              aravindsk

              do you think @Asynchronous annotaion on process method stopping from creating a new slsb?

              • 4. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                jaikiran

                1) Using java.io.* in EJBs isn't recommended.

                2) Are you sure the previous invocation on SLSB is still processing when you invoke on it the second time?

                • 5. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                  aravindsk

                  1> i only need a Bean that can process asynchronously when the timeout expires from Singleton Scheduler. is there any other way?

                             1.1> i am only simulating a long running database call  or FTP calls.

                  2> timeout event that i set in singleton is 1 sec and in the process method i was reading and copying a 200MB file.

                  • 6. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                    aravindsk

                    1. I removed @Async annotation on process method in SLSB but still it shows number of instances 1.

                     

                    i also looked at the total time spent in this method for each execution shows 67719.. is this in milliseconds?

                    • 7. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                      aravindsk

                      just curious when jb3-interceptors-aop.xml says  maxSize 30 but admin-console shows only 1 for that SLSB?

                      • 8. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                        wolfc

                        Please look at my comment on https://jira.jboss.org/browse/EJBTHREE-1703.

                        • 9. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                          aravindsk

                          I have followed your link and thinking that i should change default configured annotation pool value to something like this in ejb-intersepters-aop.xml for Stateless Bean domain.?

                           

                            <annotation expr="class(*) AND !class(@org.jboss.ejb3.annotation.Pool)">
                                    @org.jboss.ejb3.annotation.Pool (value="StrictMaxPool", maxSize=7,   timeout=10000)
                                </annotation>

                           

                          no error but i still see that each Singleton Ejb bean is referencing it's injected SLSBean as a just bean instance not as a pool instance. calls are still synchronized.

                           

                          i tried to create a new SingletonBean2 where i injected same SLSBean and started calling methods on SLSBean similler to SingleTonBean and this time two SLSBeans were created and each one associated only to their SingletonBeans.

                          what i understand from this is SLSBeans that are injected into SingletonBeans ejbs are maintained as just bean instances instead of pool instances.

                           

                          please let me know if there is anything that i am doing/expecting unusual.

                          • 10. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                            aravindsk

                            Jai: 1) Using java.io.* in EJBs isn't recommended.

                             

                            is this true for Ejb 3.1 as well?( how about Singleton EJB reading file and transforming and then calling SLSBS for persitence is this recommended?)

                            i was thinking of using SLSB to read file content and tranform into Entities for persirence. what is the recommend if Ejbs can not read files?

                            • 11. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                              wolfc

                              @Asynchronous is not yet available.

                               

                              Keep your eye on https://jira.jboss.org/browse/EJBTHREE-1721.

                              • 12. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                                jaikiran

                                aravind kopparthi wrote:

                                 

                                Jai: 1) Using java.io.* in EJBs isn't recommended.

                                 

                                is this true for Ejb 3.1 as well?( how about Singleton EJB reading file and transforming and then calling SLSBS for persitence is this recommended?)

                                i was thinking of using SLSB to read file content and tranform into Entities for persirence. what is the recommend if Ejbs can not read files?

                                It applies for EJB3.1 as well. Check section 21.2.2 "Programming Restrictions" in EJB3.1 spec for the entire set of restrictions.

                                 

                                As for java.io.* restriction, here's a quote from that section.

                                 

                                An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.

                                 

                                The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC, to store data.

                                 

                                You don't have to do the file reading part in the EJBs. Just let the EJBs persist your entities.

                                • 13. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                                  aravindsk

                                  Not that i am trying to compare two appservers. same two classes(Singleton,SLSBean) ran perfectly asynchronously as expected pooling  multiple slsbs calling slsbs' methods  from one singletonBean when i deployed it to glassfish 6.9.1. i am sure i can get some answers or resolutions from Jboss. as i am big fan of Jboss.

                                   

                                   

                                  09:06:01,234 INFO  [STDOUT] TIMEOUT METHOD CALLED
                                  09:06:13,578 INFO  [STDOUT] MetavanteProcess MetavanteProcess
                                  09:06:13,593 INFO  [STDOUT] TIMEOUT METHOD CALLED
                                  09:06:26,062 INFO  [STDOUT] MetavanteProcess MetavanteProcess
                                  09:06:26,062 INFO  [STDOUT] TIMEOUT METHOD CALLED
                                  09:06:37,953 INFO  [STDOUT] MetavanteProcess MetavanteProcess
                                  09:06:37,968 INFO  [STDOUT] TIMEOUT METHOD CALLED
                                  09:06:50,437 INFO  [STDOUT] MetavanteProcess MetavanteProcess
                                  09:06:50,437 INFO  [STDOUT] TIMEOUT METHOD CALLED
                                  09:06:59,968 INFO  [STDOUT] MetavanteProcess MetavanteProcess
                                  09:06:59,984 INFO  [STDOUT] TIMEOUT METHOD CALLED
                                  09:07:12,656 INFO  [STDOUT] MetavanteProcess MetavanteProcess
                                  09:07:12,656 INFO  [STDOUT] TIMEOUT METHOD CALLED
                                  09:07:26,593 INFO  [STDOUT] MetavanteProcess MetavanteProcess
                                  09:07:26,609 INFO  [STDOUT] TIMEOUT METHOD CALLED
                                  09:07:39,125 INFO  [STDOUT] MetavanteProcess MetavanteProcess
                                  09:07:39,125 INFO  [STDOUT] TIMEOUT METHOD CALLED

                                  loginfo: from glfish

                                   

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                  INFO: TIMEOUT METHOD CALLED

                                   

                                   

                                   

                                  loginfo from jboss: next timeout is not called until first method process completed on slsb first call

                                  09:06:01,234 INFO  [STDOUT] TIMEOUT METHOD CALLED

                                   

                                  09:06:13,578 INFO  [STDOUT]  process completed in slsb

                                   

                                  09:06:13,593 INFO  [STDOUT] TIMEOUT METHOD CALLED

                                   

                                  09:06:26,062 INFO  [STDOUT] process completed in slsb

                                   

                                  09:06:26,062 INFO  [STDOUT] TIMEOUT METHOD CALLED

                                   

                                  09:06:37,953 INFO  [STDOUT] process completed in slsb

                                   

                                  09:06:37,968 INFO  [STDOUT] TIMEOUT METHOD CALLED

                                   

                                  09:06:50,437 INFO  [STDOUT] process completed in slsb

                                   

                                  09:06:50,437 INFO  [STDOUT] TIMEOUT METHOD CALLED

                                   

                                  09:06:59,968 INFO  [STDOUT] process completed in slsb

                                   

                                   

                                   

                                  • 14. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                                    jaikiran

                                    The EJB3.1 spec says (for singleton bean concurrency):

                                     

                                    If the concurrency locking attribute is not specified, it is assumed to be Lock(WRITE). The absence of a concurrency attribute specification on the bean class is equivalent to the specification of Lock(WRITE)on the bean class.

                                     

                                     

                                    Furthermore, the spec says:

                                     

                                    If the container invokes a method associated with a Read lock, any number of other concurrent invocations on Read methods are allowed to access the bean instance simultaneously.

                                     

                                    If the container invokes a method associated with a Write lock, no other concurrent invocations will be allowed to proceed until the initial Write method’s processing completes. A concurrent access attempt that is not allowed to proceed due to locking is blocked until it can make forward progress.

                                     

                                    Your @Singleton bean doesn't specify any explicit @Lock. So it's treated by default as WRITE lock and that explains the behaviour you are seeing.

                                    1 2 3 Previous Next