[ 
https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867218#action_12867218
 ] 

Cliff Jansen commented on QPID-2589:
------------------------------------

One problem is implementing WCF's BeginSend for asynchronous writes.  There are 
three ways of using them, two shown here:

  // nothing blocks
  IOutputChannel myChannel;
  AsyncCallback sendCallback = new AsyncCallback(this.MyCallback);

  // ...
  for (i=0; i<msgcount; i++) {
    msg = myMessageFactory.Create("in loop with callback", i);
    myChannel.BeginSend(msg, TimeSpan.MaxValue, mycallbackDelegate, msg);
  }

  // alternate use
  msg = myMessageFactory.Create("polling", 0);
  IAsyncResult result = myChannel.BeginSend(msg, TimeSpan.MaxValue, null, null);
  while (!result.IsComplete) {
    // do something else
  }
  myChannel.EndSend(result);  // could raise exception here
  msg.Close();
  
//...

  void MyCallback(IAsyncResult result) {
    Message msg = (Message) result.AsyncState;
    try {
      myChannel.EndSend(result);
    }
    catch (Exception e) {
      Console.WriteLine("message send exception {0}", e);
    }

    msg.Close();
  }


I can't see how to implement this functionality in the new messaging API 
without launching a thread to monitor a write(msg, true) for every BeginSend.  
In the 0-10 API, I have a single thread that monitors an ordered list of Future 
objects:

  futurep = new Future(sessionImplp->send(mtcmd, *framesetp));

If there is exception or connection drop, the Future preserves information to 
know which messages succeeded and which ones failed.

WcfPerftest with a million messages and a million separate thread instances 
would not be pretty, even if they come from a thread pool.


Looking through the existing WCF implementation, the only other Futures that 
are used are for XaResults from the various dtx commands.  It would be nice to 
be able to preserve the async nature for these in the new API going forward.  I 
think any resource manager would want to have this capability.


> Add a .NET binding to QPID Messaging API
> ----------------------------------------
>
>                 Key: QPID-2589
>                 URL: https://issues.apache.org/jira/browse/QPID-2589
>             Project: Qpid
>          Issue Type: New Feature
>          Components: C++ Client
>    Affects Versions: 0.7
>         Environment: Windows
>            Reporter: Chuck Rolke
>            Assignee: Ted Ross
>             Fix For: 0.7
>
>         Attachments: qpid_bindings.diff
>
>
> This binding package is a .NET Interop wrapper around the Qpid Messaging 
> interface. It exposes the Messaging interface through a series of managed 
> code classes that may be used by any .NET language.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Reply via email to