Petals SE JSR181

No support for AsyncContexts

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.2
  • Fix Version/s: None
  • Component/s: None
  • Security Level: Public
  • Description:
    Hide

    The JBIContext class provides a method sendAsync( AsyncContext ac ).
    But there is no support in the component to handle these asynchronous contexts. You can put a context on the exchange but not be notified when the exchange is complete.

    • A workaround may be to mix the JSR-181 and the POJO approach (a public method in the implementation).
    • Another solution may be to have a method in the JBIContext to send asynchronously several messages.
      Example: 
      List<Exchange> exchanges = new ArrayList<Exchange> ();
for( int i=0; i<=5; i++ ) {
    // Build a set of exchanges
    exchanges.add( newExchange );
}

// Send asycnhronously all the messages
// Let the component deal with the CDK code and with the asynchronous part
JBIContext.getMessageSender().sendExchangesAsynchronously( exchanges );
    Show
    The JBIContext class provides a method sendAsync( AsyncContext ac ). But there is no support in the component to handle these asynchronous contexts. You can put a context on the exchange but not be notified when the exchange is complete.
    • A workaround may be to mix the JSR-181 and the POJO approach (a public method in the implementation).
    • Another solution may be to have a method in the JBIContext to send asynchronously several messages. Example: 
      List<Exchange> exchanges = new ArrayList<Exchange> ();
for( int i=0; i<=5; i++ ) {
    // Build a set of exchanges
    exchanges.add( newExchange );
}

// Send asycnhronously all the messages
// Let the component deal with the CDK code and with the asynchronous part
JBIContext.getMessageSender().sendExchangesAsynchronously( exchanges );
  • Environment:
    -

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Christophe DENEUX added a comment - Wed, 4 Apr 2012 - 09:18:38 +0200

For one of our customer, I have already used Future with an Executor in a SU POJO to realize concurrent service invocations.
It's not a great idea because few Futures are never terminated. We does not found why.
Thus, as a Future is not terminated, a thread of the Executor service is used. After some time, no more thread is available in the executor service (all are used by phatom Future) and the component or the Petals node must be restarted.

Another solution may be to have a method in the JBIContext to send asynchronously one message and specify the reply processing callback:

JBIContext.getMessageSender().sendAsync(exchange, new ExchangeCallback() {
   @Override
   public void onAsyncReply(Exchange exchange) {
      ...
   }

   @Override
   public void onExpiredAsyncReply(Exchange exchange) {
      ...
   }
})
Show
Christophe DENEUX added a comment - Wed, 4 Apr 2012 - 09:18:38 +0200 For one of our customer, I have already used Future with an Executor in a SU POJO to realize concurrent service invocations. It's not a great idea because few Futures are never terminated. We does not found why. Thus, as a Future is not terminated, a thread of the Executor service is used. After some time, no more thread is available in the executor service (all are used by phatom Future) and the component or the Petals node must be restarted. Another solution may be to have a method in the JBIContext to send asynchronously one message and specify the reply processing callback: 
JBIContext.getMessageSender().sendAsync(exchange, new ExchangeCallback() {
   @Override
   public void onAsyncReply(Exchange exchange) {
      ...
   }

   @Override
   public void onExpiredAsyncReply(Exchange exchange) {
      ...
   }
})
Hide
Permalink
Vincent Zurczak added a comment - Wed, 4 Apr 2012 - 10:37:48 +0200

The second option would be the best IMO.
This way, it is a real API provided by the JSR-181 component.

Show
Vincent Zurczak added a comment - Wed, 4 Apr 2012 - 10:37:48 +0200 The second option would be the best IMO. This way, it is a real API provided by the JSR-181 component.
Hide
Permalink
Vincent Zurczak added a comment - Wed, 11 Apr 2012 - 19:05:01 +0200

Asynchronous invocations are not possible for the moment.

Show
Vincent Zurczak added a comment - Wed, 11 Apr 2012 - 19:05:01 +0200 Asynchronous invocations are not possible for the moment.
Hide
Permalink
Vincent Zurczak added a comment - Wed, 11 Apr 2012 - 19:07:28 +0200

Commit #32056
A first implementation (tested, works, but does not seem very efficient).

Show
Vincent Zurczak added a comment - Wed, 11 Apr 2012 - 19:07:28 +0200 Commit #32056 A first implementation (tested, works, but does not seem very efficient).
Hide
Permalink
Vincent Zurczak added a comment - Sat, 5 May 2012 - 00:26:47 +0200

The implementation needs to be reviewed.
The commit is rolled back.

This will be done later (in the next roadmap hopefully).

Show
Vincent Zurczak added a comment - Sat, 5 May 2012 - 00:26:47 +0200 The implementation needs to be reviewed. The commit is rolled back. This will be done later (in the next roadmap hopefully).

People

Dates

  • Created:
    Fri, 23 Mar 2012 - 16:11:03 +0100
    Updated:
    Sat, 5 May 2012 - 00:26:47 +0200
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.