Concurrency throttling by default?

[milehimikey]

Hello, I have an issue that I can't seem to put a finger on. I am relatively new to Spring and am not using much more than the standard bean definitions for DI into my beans. During testing I ran into a concurrency issue with my applicaiton (a simple web application) running in Tomcat 6.0.10.

The servlet for the web app fetches the bean (MyWebBean) from WebApplicationContext loaded like this:
(in init() method)

        WebApplicationContext ctx =
                WebApplicationContextUtils.getWebApplicationContext(
                        config.getServletContext());
        if (ctx == null)
        {
            throw new RuntimeException("spring.config.broke");
        }
        this.myService =
                (MyService) ctx.getBean("MyService");

Then the service is simply used from the servlet like this:

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException
    {
...
            System.out.println("I'm about to call getFoo() at: " + new Date(System.currentTimeInMillis()));
            myReturnValue = myService.getFoo(inputParameter);
    }

The first thing myService.getFoo() does is print out to the screen as well:

public Object getFoo(InputParameter param)
{
    System.out.println("Start getFoo() at: " + new Date(System.currentTimeInMillis()));
...
}

If I run this web app from 6 separate web browser windows concurrently, 5 of the 6 work just fine...the 6th will wait until one of the other 5 is complete before sending the request to myService.getFoo() (ie. it prints 'I'm about to call getFoo()" but doesn't print "Start getFoo()" until one of the previous 5 is complete).

maxThreads in Tomcat is set to 150 and when I stop using Spring to configure MyService and force it to be a singleton on my own the issue goes away.

application context for MyService looks like this:

  <bean id="MyService"
        class="com.foo.bar.MyServiceImpl">
    <property name="loggingService" ref="LoggingService"/>
    <property name="configBean" ref="ConfigurationBean"/>
  </bean>
  <bean id="LoggingService"
        class="com.foo.bar.logging.LoggingServiceImpl"/>

  <bean id="ConfigurationBean" class="com.foo.bar.ConfigurationBeanImpl" init-method="initialize"
        destroy-method="destroyConfig">
    <property name="loggingService" ref="LoggingService"/>
  </bean>

I believe I'm missing something in Spring config...or perhaps something fundamental about Spring. Does anyone have any insight as to what may be causing this? Is there any sort of default throttling being done in Spring? I've seen reference to ConcurrencyThrottleSupport but I am not using that explicitly.

Thanks for any insight.

[al0]

Sorrz, but in zour explanation something does not fit together - zour throttling occurs after zou have obtained your service from Spring,
and at this moment service has absolutely not idea how it was created - obtained from Spring, directly instantiated with new or in some other way.

So problem for sure is somewhere else.

Regards,
Oleksandr

[milehimikey]

Yes, I understand that the service has already been instantiated and exists in the container. But I can remove Spring injection from the picture and invoke the service as a singleton like this:

private static MyService singleService;

private MyService()
{
}

public static MyService getInstance()
{
    if (singleService == null)
    {
        singleService = new MyService()
    }
    return singleService;
}

and the problem goes away.

[al0]

Yes, I understand that the service has already been instantiated and exists in the container. ...

As soon as you have reference to this objects any calls to it are not affected in any way by fact that object was instantiated by Spring. Spring just unable to introduce throttling at this very point.

Are you sure that you have not changed anything else in your code?

May you hit some memory constraints (application w/o Spring may be smaller)?

May you create a complete demo application that exhibits this behavior and post it here (as attachment)?

Regards,
Oleksandr