IndexOutOfBoundsException when invoking eagerly-injected proxy (AssociationInvocationHandler fails)

[Dawid Loubser]

Hi,

I hate to turn this list into the Dennis-'n-Dawid list, but nobody
else seems to be posting of late :-)

So - I am eagerly injecting a proxy to a service, and have configured
it as follows:

association( type: "uses", serviceType: 'net.jini.space.JavaSpace05',
property: 'space', name: 'Space')
{
serviceDiscoveryTimeout: 1
serviceDiscoveryTimeUnits : TimeUnit.HOURS
management inject: 'eager'
}

As soon as my service starts up (the proxy has been eagerly injected),
it try to do a call on this proxy, which I would expect to block until
the actual service is available (up to an hour, just for fun).
Instead, the call fails with:

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.rioproject.associations.strategy.FailOver.getService(FailOver.java:
54)
at
org.rioproject.associations.AssociationProxySupport.doInvokeService(AssociationProxySupport.java:
188)
at org.rioproject.associations.AssociationProxySupport
$AssociationInvocationHandler.invoke(AssociationProxySupport.java:426)
at $Proxy34.readIfExists(Unknown Source)


Could this be a bug in the AssociationProxySupport? Or am I
configuring something incorrectly?

[Dennis Reedy]

On Feb 23, 2012, at 644AM, Dawid Loubser wrote:

> Hi,
>
> I hate to turn this list into the Dennis-'n-Dawid list, but nobody
> else seems to be posting of late :-)
>
> So - I am eagerly injecting a proxy to a service, and have configured
> it as follows:
>
> association( type: "uses", serviceType: 'net.jini.space.JavaSpace05',
> property: 'space', name: 'Space')
> {
> serviceDiscoveryTimeout: 1
> serviceDiscoveryTimeUnits : TimeUnit.HOURS
> management inject: 'eager'
> }
>

The above declaration is not valid, if that is what you're using I dont see how that would have passed. Your declaration should look like:

association( type: "uses", serviceType: 'net.jini.space.JavaSpace05', property: 'space', name: 'Space') {

management inject:'eager', serviceDiscoveryTimeout: 1, serviceDiscoveryTimeUnits : TimeUnit.HOURS
}

> As soon as my service starts up (the proxy has been eagerly injected),
> it try to do a call on this proxy, which I would expect to block until
> the actual service is available (up to an hour, just for fun).
> Instead, the call fails with:

That was a bug in the FailOver strategy that has been fixed. FailOver tried to get the first service in a collection of services when the collection was empty.

[Dawid Loubser]

It does deploy (also in 5.0-SNAPSHOT) without complaint...

I am afraid your suggested change still does not work. When modifying
your workflow example (in 5.0-SNAPSHOT) and running (removing the code
that first polls for the space to be available) I get:

java.rmi.RemoteException: No services available for service
association [net.jini.space.JavaSpace05], name [Workflow Space],
strategy=[null], Using discovery attributes: groups=[Workflow]
locators=[] . Check network connections and ensure that the
[[net.jini.space.JavaSpace05], name [Workflow Space], strategy=[null]]
service is deployed. You may also want to check the service discovery
timeout property, it is set to [0]. Changing this value will allow Rio
to wait the specified amount of time for a service to become
available.
at
org.rioproject.associations.AssociationProxySupport.doInvokeService(AssociationProxySupport.java:
226)
at org.rioproject.associations.AssociationProxySupport
$AssociationInvocationHandler.invoke(AssociationProxySupport.java:426)
at $Proxy45.takeIfExists(Unknown Source)
at org.rioproject.examples.workflow.Worker
$SpaceProcessor.run(Worker.java:116)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:
441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)


Note the "You may also want to check the service discovery timeout
property, it is set to [0]". My configuration (modified based on your
instruction) however looks like:

service(name: name) {
implementation(class:
"org.rioproject.examples.workflow.Worker") {
artifact ref: 'service-impl'
}

parameters {
parameter name: "template", value: "${state}"
}

association(type: "requires", serviceType:
JavaSpace05.name, property: "javaSpace", name: "Workflow Space")

{
management inject:'eager', serviceDiscoveryTimeout: 1,
serviceDiscoveryTimeUnits : TimeUnit.HOURS
}

maintain 1

[Dawid Loubser]

Just an update: After hours of struggling, I still cannot get
serviceDiscoveryTimeout to work. After studying the Groovy DSL (rio-
lib/src/main/groovy/org/rioproject/opstring/
GroovyDSLOpStringParser.groovy), it's apparent that thy way in which
the time units are specified above are not correct - I believe it

should look like:

association( type: "uses", serviceType: 'net.jini.space.JavaSpace05',
property: 'space', name: 'Space')
{

management inject: 'eager', serviceDiscoveryTimeout: 15,
serviceDiscoveryTimeUnits : 'minutes'
}

(with 'minutes' being the default)

This, however, still does not set the serviceDiscoveryTimeout on the
generated AssociationDescriptor (this is the logging output):

Type=AssociationType=uses, Name=Workflow Space,
Interfaces=net.jini.space.JavaSpace05, Groups=Workflow,
MatchOnName=true, OperationalString=<null>, Property=javaSpace,
associationMatchFilter=null, proxyClass=null, proxyType=jdk,
serviceStrategyClass=null, lazyInject=false,
serviceDiscoveryTimeout=0, serviceDiscoveryTimeUnits=MINUTES,
FDH=org.rioproject.fdh.AdminFaultDetectionHandler

I have filed a bug report (http://jira.rio-project.org/browse/RIO-347)
- if anybody can spot what I'm doing wrong (if this is not a bug)
please let me know, otherwise I will patiently await Dennis' feedback.

Dawid

[Dennis Reedy]

On Feb 23, 2012, at 306PM, Dawid Loubser wrote:
>
> I have filed a bug report (http://jira.rio-project.org/browse/RIO-347)
> - if anybody can spot what I'm doing wrong (if this is not a bug)
> please let me know, otherwise I will patiently await Dennis' feedback.

You should have gotten initial feedback that I have started to look into the issue. Looks to be a bug, should have it squared away in a little while. I do have other high priority tasks that take precedence though, so it will be a day or so.

[Dawid Loubser]

Wonderful, Dennis. I am at least getting more comfortable around the
Rio codebase, so pretty soon I should be able to fork and contribute
bug fixes to problems like these - I hope. This is such a wonderful
project, everybody enjoying its benefits should contribute something
at least :-)