6 Replies Latest reply on Jan 8, 2004 3:40 AM by shieroii

    bean timeout solution...

    shieroii Newbie

      Hello everybody,

      a client calls a remote method 'timeout()' and awaits for a response. the following code shows the remote method..

      //defination of timeout() declared in remote-interface
      public int timeout() throws RemoteException {
      try {
      // perform an operation that might take 3 or more minutes..
      // this operation may or may not be related to database
      } catch (Exception e) {
      // in case of an exception..
      return -1;
      }
      // everything goes smooth..
      return 0;
      }


      now, the question is, how can I neatly manage the scenario in case the client has maximum time span of 60 seconds to wait for a response from the bean.

      I am using JBoss 3.2.2 and bean itself is a stateless session. I am searching for a bean-specific solution.... say, there might be a case where client can wait upto 120 seconds. I feel the need to say that because I have a general idea that there is an option somewhere in JBoss-property files where I can set a global timeout span for beans.

      another restriction: I dont want to set a thread - something like 'Timer' on the client end as that in my case would mean editing of my client(s) codes in several places. Thats the reason I said I am looking for a bean specific solution.

      Would also like to mention that I am relatively new to this area of java and what troubles me more is nothing else but the little knowledge of the same!

      Guys, please give your opinion/idea. Thanking you all in advance, for the same.

        • 1. Re: bean timeout solution...
          shieroii Newbie

          Hello again,

          why no replies? Any work arounds? Is there a better responding jboss related forum or news-group?

          • 2. Re: bean timeout solution...
            Adrian Brock Master

            Because you are asking for "real time" response processing from EJB
            when it is not designed as a "real time" system.

            You would have to write your own timer.

            If you don't mind being jboss-specific, you can write your own client
            interceptor to avoid changing the code.
            This processing certainly cannot be done in a portable fashion.

            Regards,
            Adrian

            • 3. Re: bean timeout solution...
              Normand Martel Newbie

              Depending on your problem/flexability to change the code, you could wrap your process with a stateless session bean (SLSB). SLSBs do support the construct of "timing out" a supposed "session". Whose to say exactly what a session might be comprised of. You might be able to work SLSBs into your solution... but that does involve making some changes to your application or client code.

              If, as you suggested in your initial post, you are constrained to existing client code, then you have to take the path Adrian is suggesting and use interceptors so that the container/environment deals with your issues (since you can not or will not change the client).

              • 4. Re: bean timeout solution...
                shieroii Newbie

                Hello again!

                thanks very much for the response. yes, I did think of implementing a timer as suggested by Adiran somthing like...

                client---> myBean.timeout() - start timer(thread) - start operation(thread)---> respond client(which ever ends first)

                ...but did not proceed as that involves the use of Threads which is not supposed to be used in EJBs.

                how do I write a client interceptor? Is there a doc giving some explanation about that?

                • 5. Re: bean timeout solution...
                  Normand Martel Newbie

                  Take a class with the JBoss group... it will likely be the easiest way to get things done AND you will have the benefit of personal contacts within the consulting group.

                  Okay, you don't want to take a class. Here's the short answer...

                  JBoss is MBEAN and interceptor-centric. That is, JBoss is deployed as a set of dynamic services which you pick and choose with various MBEANS (ala JMX). You edit the XML deployment files to launch the services you want and you connect classes and components within a service via the MBEAN.

                  You need to grasp this concept before you fo further. Once understood you will find that there is an XML file deployed to control the default interceptors for EJBs. Further, you can provide a similar file with each JAR you deploy with a set of rules and services customized for that set of beans deployed with the JAR that overrides the container defaults. It is in this user-specified XML file that you will specify a new interceptor, or modify an existing interceptor to get the behavior you want.

                  Take the default standardjbosscmp-jdbc.xml file:

                  <!-- ===================================================================== -->
                  <!-- Standard JBoss EJB Configurations -->
                  <!-- ===================================================================== -->


                  <enforce-ejb-restrictions>false</enforce-ejb-restrictions>

                  <invoker-proxy-bindings>
                  <invoker-proxy-binding>
                  entity-rmi-invoker
                  <invoker-mbean>jboss:service=invoker,type=jrmp</invoker-mbean>
                  <proxy-factory>org.jboss.proxy.ejb.ProxyFactory</proxy-factory>
                  <proxy-factory-config>
                  <client-interceptors>

                  org.jboss.proxy.ejb.HomeInterceptor
                  org.jboss.proxy.SecurityInterceptor
                  org.jboss.proxy.TransactionInterceptor
                  org.jboss.invocation.InvokerInterceptor


                  org.jboss.proxy.ejb.EntityInterceptor
                  org.jboss.proxy.SecurityInterceptor
                  org.jboss.proxy.TransactionInterceptor
                  org.jboss.invocation.InvokerInterceptor

                  <list-entity>
                  org.jboss.proxy.ejb.ListEntityInterceptor
                  org.jboss.proxy.SecurityInterceptor
                  org.jboss.proxy.TransactionInterceptor
                  org.jboss.invocation.InvokerInterceptor
                  </list-entity>
                  </client-interceptors>
                  </proxy-factory-config>
                  </invoker-proxy-binding>

                  In this snippet, notice that there is a section for the <client-interceptors> and the interface. You can modify/extend an existing interceptor or you can add your own interceptor and use that in place of the containers default interceptor. The way you replace the containers behavior is by naming your interceptor differently and plugging that into the MBEAN/XML file that is deployed with your JAR. This way, the container will defer processing to your interceptor for the specific BEAN(s) and use the container default for everything else.

                  I would suggest getting someone to help you under a consultation arrangement as this will get you through the hurdles quickly. Your solution will depend on what exactly it is you want to time/timeout. The person coding up/designing your solution will need to understand your application and problem in detail in order to provide the right solution (code).

                  • 6. Re: bean timeout solution...
                    shieroii Newbie

                    Hi Normand,

                    thanks for your suggestion. yes, from the experience that I have had with JBoss in recent days especially with its limited and incomplete docs (free of course), I am left with no choice but as you suggested, to have an consultation with JBoss group... well, I am not the person in my organisation to decide over this consultation but I am certainly the one who can initiate this... but before that I will have to have some info like the time and cost involved in the training etc.

                    anyways, thanks once again, for the clues.