6 Replies Latest reply: Jun 1, 2012 5:18 AM by Kristian Ivarsson RSS

    TPELIMIT and tpacall

    Kristian Ivarsson
      Hi folks,

      I have read somewhere that the current limit of outstanding requests is 50

      Does anyone know if the limit of maximum outstanding replies is bound to a single application/service/process or may the aggregated concurrent outstanding replies within a domain result in that a certain service will receive TPELIMIT "premature" (i.e. before 50) ?

      If it is a restriction to every single application, is the limit defined somewhere ?

      Best regards,
      Kristian

      p.s.
      Does anyone know why such a restriction even exists ?
      d.s.
        • 1. Re: TPELIMIT and tpacall
          user734005
          The TPELIMIT with tpacall is on the requesting "client" process. It is not system wide within Tuxedo. A single "client" process making the tpacall can have up to 50 tpacall's outstanding before before issueing the tpgetreply.
          • 2. Re: TPELIMIT and tpacall
            Kristian Ivarsson
            Hi user734005 and others,

            and thanx (I should have used the phrase "client" instead of application/process/service)

            Since this limit of 50 might be a subject to change, is it defined somewhere in some header-file or is it possible to retrieve it in runtime etc ?

            Does anyone know why such limit exists ? Does anyone have a hunch if a change-request (i.e. don't have an explicit limit) would be considered by Oracle ?

            Best regards,
            Kristian
            • 3. Re: TPELIMIT and tpacall
              Todd Little-Oracle
              Hi Kristian,

              I believe the actual limit is 50 outstanding calls for a given Tuxedo context. Since a client can be multi-contexted, it should be possible to have more than 50 outstanding calls within a single client.

              As to why and how to get the number... For each outstanding call, Tuxedo maintains an internal handle in a table. The size of this table is set to TM_MAXHANDLES. Unfortunately this macro is not defined in a publicly published header file.

              You can certainly raise an enhancement request, although I'd have to ask why you need more than 50 outstanding calls for a single context.

              Regards,
              Todd Little
              Oracle Tuxedo Chief Architect
              • 4. Re: TPELIMIT and tpacall
                Kristian Ivarsson
                Hi Todd,

                unfortunately (or actually fortunately) we're just working with single threaded applications

                The reason why we sometimes wanna have more than 50 outstanding requests is because of our semi-SOA-design-patterns that in some cases makes us wanna operate on any given amout of data in a generic way e.g. fetch information for every customer in list and because of performance you do want to do that parallell (instead of a sequence). Of cource this could be done with multi-threading but that's not how we do it (today)

                To solve this problem with the (single-threaded) patterns we're using today, the application need to be aware of this secret limit and burst away 50 requests at time and then go on to the next 50. Of course we understand that there's some physical limits, but to us; the limit of 50 just seems like a obstinate obstacle

                The reason why we prematurely need to check/handle this, is because Tuxedo prohibits you to perform further calls (with reply) if the transaction is in rollback-only-mode (which happens when tpacall returns -1)

                Ok, another solution would be to multi-thread us, but that's a bigger challenge for us (now)

                Thanx for giving this attention. We will consider a change-request (at least to be able to get the current limit)

                Best regards,
                Kristian
                • 5. Re: TPELIMIT and tpacall
                  Todd Little-Oracle
                  Hi Kristian,

                  If your process is a Tuxedo client, it can be multi-contexted without being multi-threaded. If the process is a Tuxedo server, Tuxedo will transparently multi-thread the server for you, although obviously your code would need to be thread safe. I'm not sure if that helps.

                  Regards,
                  Todd Little
                  Oracle Tuxedo Chief Architect
                  • 6. Re: TPELIMIT and tpacall
                    Kristian Ivarsson
                    Hi Todd,

                    when you're mentioning "Tuxedo will transparently multi-thread the server for you", do you refer to "Server-Dispatched Threads" ? If so, I guess that will not solve our immediate design-problem, 'cause:
                    - all our code is likely not thread-safe
                    - we're promising Tuxedo to not use threads (by setting TMNOTHREADS=YES)
                    - multiple server-dispath-threads is semanticly almost equal to having multiple instances/processes adverticed for the same service (right?)

                    Our objective is that a single-threaded-server (service) needs to retrieve information to a given amount of entities, that (today) only can be made by doin' the same number of service-calls. We wish, without using application-created threads, to be able to call this service concurrently by using tpacall instead of in a sequence ('cause of performance) (and yes, we know that the bottleneck might be the number of instances/threads in the server providing the service). The number of entities (i.e. tpacalls) will in most cases be below 50, but in every place you wanna do this, you have to have some logic where you preventively handle at most 50 a time (and so on) or else you might get a -1 from tpacall and the transaction is set to rollback-only mode and (in Tuxedo) you can't do any further calls (with reply). Ok, in some cases you might be able to tpacall with TPNOTRAN but that is not always applicable

                    Ok, there are a few design/implementation-patterns that can be made solving the prime issue, but the several-tpacall-solution seemed to be the easiest one except for that limit-of-50-obsticle. And yes, we know that doing more than 50 concurrent calls might get lower performance then calling them in a sequence, but if 98% of all the transactions handles less than, let say, 10, then it we figure it would give an overall performance boost

                    We will file an enhancement request

                    Better than best regards,
                    Kristian Ivarsson
                    Försäkringskassan IT Junior Developer