[grpc-io] java concurrent ordered response buffer

[Piotr Morgwai Kotarbinski]

Hello
i have a stream of messages coming from a websocket or a grpc client. for 
each message my service produces 0 or more reply messages. by default both 
websocket endpoints and grpc request observers are guaranteed to be called 
by maximum 1 thread concurrently, so my replies are sent in the same order 
as requests. Now I want to dispatch request processing to other threads and 
process them in parallel, but still keep the order. Therefore, I need some 
"concurrent ordered response buffer", which will buffer replies to a given 
request message until processing of previous requests is finished and 
replies to them are sent (in order they were produced within each "request 
bucket").

I can develop such class myself, but it seems a common case, so I was 
wondering if maybe such thing already exists (to not reinvent the wheel). 
however I could not easily find anything on the web nor get any answer on SO 

. does anyone knows about something like this?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/56f93d6b-2cce-422a-ae24-8f189d6ef578n%40googlegroups.com.

[grpc-io] gRPC-Core Release 1.37.0

['Richard Belleville' via grpc.io]

This is the 1.37.0(gilded 
) release 
announcement for gRPC-Core and the wrapped languages C++, C#, Objective-C, 
Python, PHP and Ruby. The latest release notes are here 
.

*Core*
   
   - Bump up minimum supported clang to 4.0. (#25443 
   )
   - Use URI form of address for channelz listen node. (#25785 
   )
   - Implementation CSDS (xDS Config Dump). (#25038 
   )
   - Don't assume that c-ares won't retry failed writes in 
   grpc_core::GrpcPolledFdWindows::SendVUDP. (#25726 
   )
   - Fix an infinite read loop with SRV record resolution on windows. (
   #25672 )
   - xDS status notifier. (#25321 )
   - Remove CAS loops in global subchannel pool and simplify subchannel 
   refcounting. (#25485 )
   - Add missing security field to channelz Socket. (#25593 
   )
   - Disable check_call_host when server_verification_option is not 
   GRPC_TLS_SERVER_VERIFICATION. (#25577 
   )

*C++*
   
   - Remove fault injection environmental variable guard. (#25792 
   )
   - Implement C++ Admin Interface API. (#25753 
   )
   - cmake: Reflect minor version change in SONAME for C++ and C#. (#25617 
   )
   - xDS Client-Side Fault Injection. (#24354 
   )

*C#*
   
   - [C#] Add buildTransitive directory to NuGet package. (#25385 
   )
   - Reduce Grpc.Core nuget size by generating separate .so with/without 
   debug symbols for grpc_csharp_ext. (#25729 
   )
   - make Grpc C# work on aarch64 linux. (#25717 
   )
   - Add support for additional protoc arguments in Grpc.Tools. (#25374 
   )
   - C#: Use explicit native extension loading whenever possible. (#25490 
   )

*Python*
   
   - use boringssl asm optimizations in aarch64 wheel source build. (#25453 
   )
   - Clarify Guarantees about grpc.Future Interface. (#25383 
   )
   - Use crosscompilation to build python armv7 wheels. (#25704 
   )
   - [Aio] Add time_remaining method to ServicerContext. (#25719 
   )
   - Standardize all environment variable boolean configuration in python's 
   setup.py. (#25444 )
   - Crosscompile python aarch64 wheels with dockcross. (#25418 
   )
   - Fix Signal Safety Issue. (#25394 
   )

*Ruby*
   
   - Cherry-pick PR #25429  "Add 
   ruby 3.0 support for mac binary packages" to 1.37.x. (#25869 
   )
   - Include GRPC::GenericService from root namespace. (#25153 
   )
   - Ruby: support for PSM security. (#25330 
   )


-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/f7f2eee2-8ccb-4bfe-ae00-cd96d71310ddn%40googlegroups.com.

Re: [grpc-io] USB as a transport channel for gRPC

[Thong Nguyen]

Thank you very much!
On Tuesday, April 20, 2021 at 2:50:43 PM UTC+9 frederic@gmail.com wrote:

> Hello Thong,
>
> Sure, you can find a work in progress on my personnal fork (branch 
> grpc-usb-1.35.0: https://github.com/fmartinsons/grpc/tree/grpc-usb-1.35.0) 
> .
>
> The code compils and run on my target machine (an embedded linux box with 
> a core i3) but for the moment I'm not able to make my android client talk 
> with the server (I have spurious USB disconnection at server side).  I had 
> not the time to go further on my investigations but I'm willing to pursue 
> as soon as possible.
>
> Anyway feel free to use this code but be warned it may not work out of the 
> box. I you find bug or improvements on that, I will be very happy to  get 
> them in a merge request (or by other means).
>
> On Tue, 20 Apr 2021 at 04:15, Thong Nguyen  wrote:
>
>> Hi  Frédéric Martinsons,
>>
>> I have need to use grpc over usb and it is very interesting that you had 
>> done it. Could you please share it with us? 
>> Many thanks!
>>
>> Thong.
>>
>> On Saturday, February 27, 2021 at 3:00:34 AM UTC+9 frederic@gmail.com 
>> wrote:
>>
>>> Thanks Nicolas, I will read the doc you pointed and make the fork in the 
>>> coming days (weeks maybe :p). 
>>>
>>> One last question that come to my mind. Like I said in the above 
>>> mentioned thread, the person who develop the patch is gone and I'm taking 
>>> responsability for the code. 
>>> I can make it compile on Linux, test it for our use cases (Android 
>>> device in accessory mode) but I don't know if the patches will be correct 
>>> towards coding rules or grpc philosophy.
>>> And, if I understood correctly, doing the fork means that no peer review 
>>> will be done to comment and accept the patches but I'm willing to have 
>>> advices about how to do better integration inside gRPC world. 
>>> Si here is my question (finally) : do you think it is possible to have 
>>> review from gRPC devs people? 
>>>
>>>
>>>
>>>
>>>
>>> Le ven. 26 févr. 2021 à 18:23, Nicolas Noble  a 
>>> écrit :
>>>
 I would direct you to 
 https://github.com/grpc/grpc-community/blob/master/grpc_ecosystem.md 
 for details on how to proceed, but, in short:

 - transfer of ownership is a very straightforward process using github: 
 https://docs.github.com/en/github/administering-a-repository/transferring-a-repository
 - being in the ecosystem organization means way less stringent rules; 
 you get to decide what's best for building and distributing your version. 
 If you wish to restrict it to Linux, and remove all of the wrapped 
 languages but C/C++, go for it.

 On Thu, Feb 25, 2021 at 10:13 PM Frédéric Martinsons <
 frederic@gmail.com> wrote:

> Ok I understand the point but I missed some details:
>- I can fork grpc to my github account but how to give it to the 
> grpc-ecosystem ?
>- For adding libusb dependency, am I obliged to go through 
> third_party git submodule and compile libusb from sources ? Or can I only 
> relies on system package (if so , where do I put it, directly in 
> CMakeLists.txt) ?
>- I have only a test setup running on unix , will it be acceptable 
> for this fork to be only unix compatible ? Or do I need to support 
> windows, 
> apple ... ?
>
> Thanks again for your quick answer by the way. Have a nice day !
>
> On Friday, 26 February 2021 at 04:12:32 UTC+1 pixel...@gmail.com 
> wrote:
>
>> Hi,
>>
>>   While the idea is interesting and has merit, adding a libusb 
>> dependency into a network-oriented library seems counter productive and 
>> would likely complexify our build, test, distribution, and maintenance 
>> burden. This seems like an endeavor that'd be much more appropriate as a 
>> specific fork; call it grpc-usb if you want, and it'd ONLY have USB as a 
>> transport mechanism. We wouldn't mind hosting it in our grpc-ecosystem 
>> organization for instance.
>>
>> On Thu, Feb 25, 2021 at 8:35 AM Frédéric Martinsons <
>> frederic@gmail.com> wrote:
>>
>>> Hello guys, like I said in a previous message (
>>> https://groups.google.com/g/grpc-io/c/rCOTPM65A7U) , back in the 
>>> day, in my company there was a use cases to having gRPC work through 
>>> usb. 
>>> We made patches for that and we would like to submit it to the project.
>>>
>>> Two questions though:
>>>   - Is is wanted and will it be acceptable for the project (does it 
>>> worth the shot to rebase and clean ourpatches) ?
>>>   - If yes, then our patches introduced a libusb dependency (
>>> https://libusb.info/) and I'm wondering what is the best way to 
>>> introduce that ? In a new third party submodule ? Is there 
>>> documentation 
>>> about integrating a new submodule because I read 
>>> https://github.com/grpc/grpc/blob/master/third_party/README.md