Skip to content

Is using Aeron stable with RSocket? #653

@CodeMason

Description

@CodeMason

The readme states that Aeron is available for use, however from looking at the issues and at stackoverflow, the comment I wouldn't recommend using the Aeron implementation currently. bothers me.

So before spending the engineering effort to use RSocket + Aeron, and for the sake of clarity, can we use Aeron right now (0.12.2-RC4) with rsocket-java?

Activity

robertroeser

robertroeser commented on Jun 20, 2019

@robertroeser
Member

Aeron+RSocket isn't production worthy right now - I have an an update but we haven't really found the need to use Aeron right now. What's your use-case?

CodeMason

CodeMason commented on Jun 20, 2019

@CodeMason
Author

We're using aeron to push huge amounts of data between servers, and are interested in RSocket features.

ronenhamias

ronenhamias commented on Nov 13, 2019

@ronenhamias

@CodeMason
as part of our research to implement reactor aeron we where also interested to implement rsocket aeron. https://github.com/scalecube/rsocket-transport-aeron

one issue we found with integrating Rsocket with Aeron is the use of netty byte buffers currently there is no way in rsocket implementation to introduce an alternative byte buffer.
this restriction forces to copy the byte buffers from aeron to netty and causes performance impact.

please check
https://github.com/scalecube/reactor-aeron

OlegDokuka

OlegDokuka commented on Nov 13, 2019

@OlegDokuka
Member

Hey @ronenhamias!

The main reason for coping with BB is to have the power of refcounting and subsequent ability to deal with multithreading (which is less possible for Aeron buffers (correct me if I'm wrong)). Thus, I'm curious how do you solve that in rector-aeron and how do you cope with multithreading, the asynchronous reactor in your case?

Regards,
Oleh

ronenhamias

ronenhamias commented on Nov 14, 2019

@ronenhamias

Hey @OlegDokuka! :)

the reasons are clear and netty is great probably for most of use cases. netty BB is a powerful thing. on the other hand aeron does not know anything about netty BB so if someone see a need/have an aeron use-case then the restriction of using netty BB with argona BB causes additional copy just for the sake of fitting aeron to rsocket abstractions. in such case this someone will not enjoy the benefits of aeron and his exceptions will not be met as aeron implies a very specific way of doing things.
in such case i think its better to use just plain aeron or reactor-aeron or giving up on aeron so it really depends on the usecase and requirements.

Regards,
Ronen.

ebfhub

ebfhub commented on Feb 3, 2020

@ebfhub

I might be wrong, but I think you can do this.
Note that the UnsafeBuffer should belong to the thread calling offer(), and can be reused after offer() returns.

        static final UnsafeBuffer buffer = new UnsafeBuffer();
        if (bb.hasArray()) {
            buffer.wrap(bb.array(),0,len);
        } else if (bb.hasMemoryAddress()){
            buffer.wrap(bb.memoryAddress(),len);
        } else {
            ...??... throw
        }

       pub.offer(buffer,0,len);

And something like this for reading:

ByteBufWrappingDirectBuffer .java

OlegDokuka

OlegDokuka commented on Feb 7, 2020

@OlegDokuka
Member

@ebfhub do you have any samples of usage of mentioned BB?

I'm really curious to see how it is used in any project to fully understand whether we can adopt that as well with no subsequent issues related to asynchronous propagation of the given instance

Regards,
Oleh

ebfhub

ebfhub commented on Feb 7, 2020

@ebfhub

Sorry, only in an internal project. Following through offer(), the passed buffer is copied into another before returning, i.e. on the return from offer() you can reuse that buffer.
e.g.
termBuffer.putBytes(termOffset + HEADER_LENGTH, srcBuffer, srcOffset, length);

On the receive side, the ByteBufWrappingDirectBuffer would need to be used synchronously (which we do.)

OlegDokuka

OlegDokuka commented on Feb 9, 2020

@OlegDokuka
Member

Gotcha. Actually, I can imagine just minor limitation on such a transport which requires to deserialize before sending on another thread which should be fine

self-assigned this
on Feb 9, 2020
added this to the Backlog milestone on Apr 22, 2021
burakakca

burakakca commented on Jan 15, 2023

@burakakca

What is the current status of this topic?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Relationships

None yet

    Development

    Participants

    @yschimke@ronenhamias@CodeMason@OlegDokuka@ebfhub

    Issue actions

      Is using Aeron stable with RSocket? · Issue #653 · rsocket/rsocket-java