Reducing Java object lock contention in org.jboss.invocation

[smarlow]

I would like to try to reduce the object lock contention in PooledInvokerProxy.getPooledConnection(). We currently hold the lock while testing the connection and I think we could do a little better.

I will a open a jira for tracking the work and will discuss the change proposal here.

Scott

[smarlow]

The jira is JBAS-4047.

[smarlow]

I left one part out. I also want to remove the "synchronized" on getPooledConnection() + returnConnection().

I don't think that we need to lock on both the instance variable "pool" and the class instance of PooledInvokerProxy.

I also see that we don't hold the lock as long anymore (we release it before testing the connection).

[starksm64]

I would like to see the pooled invoker redone to suppor the concurrent pool interfaces and make better use of its concurrency classes. However, we are moving to the remoting versions in 4.2+ as far as I understand. What version are you targetting for this change?

[smarlow]

I would like to get the change into 4.0.5sp1 if there is time (or a 4.0.x something release). What do you recommend?

I didn't know about the switch to using remoting in 4.2, so it doesn't make sense to make my proposed change there.

[starksm64]

We decided to move to a 4.2.x basis for the javaee 1.4 platform to make java5 the base jdk and update some jboss/thirdparty dependencies that could not go into another minor release of 4.0.x. At this point 4.0.x is in maintence mode with no planned next release and 4.2.0 will essentially be the next javaee 1.4 platform release.

This will still have the pooled invoker available as far as I understand. The question back is do you really want to use that invoker or would you want to switch to the remoting/unified invoker?

[smarlow]

I want to use the remoting/unified invoker but would like the option to use the pooled invoker with JBoss AS 4.2.x for a few 4.2.x releases (as a fallback solution).

I think the change is pretty simple and unless I'm missing something, is thread-safe.

I haven't run the test-suite yet to test the change, but I will (I don't remember which build target to use).

[starksm64]

The full testsuite is run using the tests target in the testsuite module. There are several other sub starting points:

[starksm@succubus testsuite]$ ant -projecthelp
Buildfile: build.xml

Main targets:

all Builds everything.
clean Cleans up most generated files.
clobber Cleans up all generated files.
compile Compile all source files.
deployment-service-tests Tests targeting the deployment service
docs Builds all documentation.
help Displays the project help
iiop-test Execute a single test.
jars Builds all jar files.
jboss-all-config-tests The units tests which are run against the jboss all config
jboss-minimal-tests Validate the minimal config
main Executes the default target (most).
most Builds almost everything.
netboot-tests Tests run against a custom netboot configuration
one-test Execute a single test.
one-test-debug Execute a single test.
one-test-ssl Execute a single test.
reports Generates all reports.
test Execute a a group of tests
test-example-binding-manager Test the example binding configuration
tests Execute all non-benchmark tests.
tests-aop-scoped AOP tests requiring a native classloader hook
tests-apache Test that apache can be started/stopped from ant
tests-apache-tomcat-clustering Execute clustering tests requiring an apache load balanced two TC nodes.
tests-clustering Execute clustering tests requiring two nodes.
tests-clustering-all-stacks Execute clustering tests requiring two nodes.
tests-compatibility Checks compatibility on SerialUUID
tests-custom-securitymgr Tests run against a jboss server with custom security manager configured
tests-deployment Execute deployment Tests
tests-ha Execute ha tests.
tests-jacc-security Tests run against a jboss server with JACC configured
tests-jacc-security-external Tests run against a jboss server with JACC configured with an external policy provider
tests-jacc-securitymgr Tests run against a jboss server with JACC configured + security manager
tests-jboss-cluster Test that two jboss cluster nodes can be started/stopped from ant
tests-matrix Executes only the version check compatibility suite. Use -Dmatrix-versions=[version container] for this task
tests-security-manager Tests run against a jboss server with a security manager
tests-stress Execute all stress tests.
tests-webservice Execute JBossWS Tests
tests-webservice-ssl Tomcat tests requiring an SSL connector
tests-wsrp-integration Execute WSRP Integration Tests
tomcat-federation-tests Tomcat tests requiring Federation configured
tomcat-ssl-tests Tomcat tests requiring an SSL connector
tomcat-sso-clustered-tests Tomcat tests requiring clustered SSO configured
tomcat-sso-tests Tomcat tests requiring SSO configured
tomcat-webctx-tests Tomcat tests requiring classloader set to the web loader
Default target: main

Nothing uses the pooled invoker by default though, so to run the basic pooled invoker tests from the org.jboss.test.pooled package:

ant -Dtest=pooled test

[smarlow]

I tried "ant -Dtest=pooled test" on windows xp professional and got the following error:

<testcase classname="org.jboss.test.pooled.test.BeanStressTestCase" name="testNewProxy" time="6.016">^M
<error message="Could not obtain connection to any of these urls: localhost:1099 and discovery failed with error: javax.naming.CommunicationException: Recei
ve timed out [Root exception is java.net.SocketTimeoutException: Receive timed out]" type="javax.naming.CommunicationException">javax.naming.CommunicationExcept
ion: Could not obtain connection to any of these urls: localhost:1099 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [R
oot exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server localho
st:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server localhost:1099 [Root exception is java.net.ConnectException: Co
nnection refused: connect]]]^M
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)^M
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)^M
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)^M
at javax.naming.InitialContext.lookup(InitialContext.java:351)^M
at org.jboss.test.pooled.test.BeanStressTestCase.runNewProxy(BeanStressTestCase.java:166)^M
at org.jboss.test.pooled.test.BeanStressTestCase.testNewProxy(BeanStressTestCase.java:151)^M
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)^M
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)^M
at junit.extensions.TestSetup.run(TestSetup.java:23)^M
Caused by: javax.naming.CommunicationException: Failed to connect to server localhost:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed t
o connect to server localhost:1099 [Root exception is java.net.ConnectException: Connection refused: connect]]^M
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)^M

I didn't see any messages about the app server being launched as I have seen before with the clustering tests (although I was on Linux when running those). My Windows firewall is disabled and port 1099 appears to be available ("netstat -a | grep 1099" matches nothing).

I also looked in the ..\build\output\jboss-4.2.0.CR1\server\ folder and only see default+all+minimal folders (log folder doesn't exist in any of the server folders).

Any ideas why the app server wouldn't be launched by this (ant -Dtest=pooled test) test?

[brian.stansberry]

You need to launch it manually. A pain, although you'll mind less if you end up running your test 10 times while you debug the test and only have to wait for the server to start once. :)

[smarlow]

Launching the server manually did it! The test passed without my changes, I'll try again with my proposed change. Thanks for the help!

[smarlow]

The unit test also passes with the proposed code change.

[smarlow]

Any objections to checking this into the 4.2 branch?

How about 4.0 (4.0.5sp1) branch?

[starksm64]

No objections. It should be synced with trunk as well.