RE: Using netstd client to call Java server

[John Bartak]

Looking more closely at all the methods that got generated, the problem only 
seems to exist if the method already ended in "Async".  I just assumed they 
were all messed up.  Sorry about that.

So here's the actual method definition that's causing a problem:

service TProducer extends commons.TLifecycle {
    commons.TSuccessFailureResponse produceAsync(1:list<commons.TEvent> events) 
throws (1: TBufferException ex1, 2: commons.TInvalidArgumentException ex2);
    i64 getTotalBytesSent();
}

This generates the following:

    public async global::System.Threading.Tasks.Task<TSuccessFailureResponse> 
produceAsyncAsync(List<TEvent> events, CancellationToken cancellationToken = 
default)
    {
      await OutputProtocol.WriteMessageBeginAsync(new 
TMessage("produceAsyncAsync", TMessageType.Call, SeqId), cancellationToken);
      ...


    public async global::System.Threading.Tasks.Task<long> 
getTotalBytesSentAsync(CancellationToken cancellationToken = default)
    {
      await OutputProtocol.WriteMessageBeginAsync(new 
TMessage("getTotalBytesSent", TMessageType.Call, SeqId), cancellationToken);
     ...

I'll see if I can figure this out and send you a PR fixing this sometime next 
week. 

Thanks.
John


-----Original Message-----
From: Jens Geyer <jensge...@hotmail.com> 
Sent: Friday, April 9, 2021 12:34 AM
To: user@thrift.apache.org
Subject: Re: Using netstd client to call Java server

Hi,

great question!

> For example, if I define a method call "foo" in my service definition 
> in the .thrift file, it creates a method "fooAsync" in the netstd 
> client and "foo" on the Java service.

The Async postfix is actually a (compatibility) leftover from the csharp 
version of the library which suppotred both, synchrfonous (without the
"Async") and await/async style calls. To distinguish between the two, the Async 
postfix was added. So theoretically we could remove it (patch
appreciated) but we need to keep the old behaviour available with some sort of 
a compatiblity switch.


> So I suppose I could write a shell script on our build server to fixup 
> the generated .cs files at build time, but that seems cumbersome.

No you're not. Why would you want to waste time doing that? The call works, 
because the wire format is 100% identical, despite the name it has in the C# 
sources. If you find a case where it does not work: file a ticket and add the 
test case so we can reproduce it.


>  I have tried manually changing the generated code from:
> await oprot.WriteMessageBeginAsync(new TMessage("fooASync", ...


I can't find that in the code. Where does that come from? And why it is spelled 
"ASync"? We are of course not responsible for any changes you (or someone else) 
made to the compiler on your own.


This is what is actually generated (current master, should be same with any 
0.14.x or any previous version supporting netstd):

C# call

      await OutputProtocol.WriteMessageBeginAsync(new TMessage("Foo", 
TMessageType.Call, SeqId), cancellationToken);

C# processor:

    public AsyncProcessor(IAsync iAsync, ILogger<AsyncProcessor> logger =
default) {
       // ... some stuff omitted
      processMap_["Foo"] = Foo_ProcessAsync;
    }

Java call:

        prot.writeMessageBegin(new
org.apache.thrift.protocol.TMessage("Foo",
org.apache.thrift.protocol.TMessageType.CALL, 0));

Java processor:

    private static ... getProcessMap(...) {
      processMap.put("Foo", new Foo());
      return processMap;
    }

Have fun,.
JensG