Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question
0

InterruptedException when invoking ExecutorProxy from client main

Following the documentation of gigaspace’s executor based remoting (http://www.gigaspaces.com/wiki/display/XAP7/ExecutorBasedRemoting), I created and deployed to gigaspace a remote service that provides both synchronous and asynchronous implementation.

If invoking the same remote service from within the server side, it doesn’t have any problem.
However, when trying to invoke remotely through the ExecutorProxy, both synch and asynch invocation got the same exception:

2011-01-10 13:20:52,339 INFO BrokerFinderRemoting - BrokerFinderRemoting finding BrokerPeerRows, brokerFinder == null?false
java.lang.InterruptedException
      at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source)
      at com.gigaspaces.lrmi.nio.async.LRMIFuture.get(LRMIFuture.java:140)
      at org.openspaces.core.transaction.internal.InternalAsyncFuture.get(InternalAsyncFuture.java:83)
      at org.openspaces.remoting.ExecutorSpaceRemotingProxyFactoryBean$ExecutorAsyncFuture.get(ExecutorSpaceRemotingProxyFactoryBean.java:399)
at com.itgssi.apr.attrade.client.AtTradeClient.main(AtTradeClient.java:60)

But on the GS monitor, I can see on the server side, the remoting service was invoked and executed accordingly successfully

2011-01-10 13:20:52,433INFO FinderService - Number of BrokerPeerRow with number of shares = 1800 in space:190
2011-01-10 13:20:52,433INFO FinderService - Found top 10 BrokerPeerRow with number of shares > 1800: 10 BrokerPeerRow.

Here’s the snippet on the client invocation, the interrupted exception happens when either using AsyncFuture get or using brokerFinderRemoting.findBrokerPeerRows(null):

Client invocation in client main()(note that, below using synch or async got the same interrupted exception):


List<String> configs = new LinkedList<String>();
configs.add("classpath:/META-INF/spring/pu.xml");

final StandaloneContainerRunnable runnable = new StandaloneContainerRunnable(null,
                null, configs);

  BrokerFinderRemoting brokerFinderRemoting = runnable.getApplicationContext().getBean(BrokerFinderRemoting.class);
        List<BrokerPeerRow> rows = brokerFinderRemoting.findBrokerPeerRows(null);
// AsyncFuture<List<BrokerPeerRow>> futureRows = brokerFinderRemoting.asyncFindBrokerPeerRows(null);
            /*try {
                  rows = futureRows.get(3, TimeUnit.SECONDS);
            } catch (InterruptedException e) {
                  e.printStackTrace();
            } catch (ExecutionException e) {
                  e.printStackTrace();
            } catch (TimeoutException e) {
                  e.printStackTrace();
            }*/
if (rows != null) {

for(BrokerPeerRow brokerPeerRow : rows) {
                        log.info(brokerPeerRow);
                  }
            }

One thing noted is, If have eclipse debugger suspend VM for InterruptedException, then the client runs just fine, no problem in getting the result any more. The GS objects that involve in throwing InterruptedException are LookupDiscovery.Requestor.run and SelfCleaningTable.Cleaner.run(when trying to remove weak reference) --- both running in daemon thread. But it’s still unclear to me which one and why it caused the interrupted exception without debugging its source code…

Any help'd be appreciated!
-Ken

This thread was imported from the previous forum.
For your reference, the original is available here

asked 2011-01-11 19:03:52 -0600

kentrade gravatar image

updated 2013-08-08 09:52:00 -0600

jaissefsfex gravatar image
edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
0

It seems like your main thread is at interrupted state (the thread that is calling the brokerFinderRemoting.asyncFindBrokerPeerRows() method).
It fits perfectly to what you are describing since a thread at interrupted state will throw interrupted exception once it needs to wait for a result from a future.
You can check that by calling Thread.currentThread().isInterrupted() before the remote invocation.

If this is the case, double check the code before this proxy creation and usage that it does not generate some interrupted exception that keeps the thread in interrupted state (for instance if the exception is thrown somewhere and caught and a call to Thread.currentThread().interrupt() is being made to restore its interrupted state).

Eitan

answered 2011-01-12 00:52:59 -0600

eitany gravatar image
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2011-01-11 19:03:52 -0600

Seen: 105 times

Last updated: Jan 12 '11