• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Throttling

 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a server processing requests on a pool of some number of threads. It happens to be EJB but that may not matter. Many different types of requests come in and go to threads first come first serve I guess.

We handle most requests in tenths of a second. But many requests make calls out to partner systems and every once in a while there is a problem that causes us to get no response. The request times out in the container defult 120 seconds.

One thread blocking that long isn't much of a problem but it doesn't take long before the same kind of request to the same sick partner comes in on all the other threads, and the whole pool is blocked. The container makes more threads up to some limit but that only bogs the server down with resource issues and they all get stuck soon enough.

So I'd like to say "out of 50 threads in the pool, never use more than 15 on partner X" The 16th request can't block because that's the problem we're trying to eliminate. I think I want the 16th request to throw a "partner service busy" exception.

I'm thinking about a named pool of tokens. The "CallPartnerX" service would try to get a token from the "PartnerX" pool. So this feels like a map of some collection.

Any other ideas?
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

So I'd like to say "out of 50 threads in the pool, never use more than 15 on partner X" The 16th request can't block because that's the problem we're trying to eliminate. I think I want the 16th request to throw a "partner service busy" exception.

I'm thinking about a named pool of tokens. The "CallPartnerX" service would try to get a token from the "PartnerX" pool. So this feels like a map of some collection.

Any other ideas?



If you are using Java 5, the "pool of tokens" that you are considering is already available. Of course, they call it a "set of permits"...

Anyway, take a look at the Semaphore class for more details.

Henry
 
Ranch Hand
Posts: 291
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're in the wrong forum. You belong in the EJB and other J2EE technologies.

You do not have access to threads in the EJB container.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, EJB is tough on that, so I don't intend to start or stop any threads. I don't think EJB has any other knobs and levers to offer me though, so I didn't go there. It's really neither treads or EJB I guess.

One feature of this framework is that all requests come through one bean that dispatches to different POJOs, so there's no opportunity in EJB land to configure the number of instances for different beans. We need this control way down in fine-grained POJO Strategies where EJB tuning options won't go.

We're running WAS 5.x and JRE 1.3.1.x ... we are held to the Java version by our vendor package for now. We'll be doing some 1.4 testing later unless I can convince the right folks to let us try 5.
 
reply
    Bookmark Topic Watch Topic
  • New Topic