Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:20
    nguyenquangminh starred dotnet/orleans
  • 08:25
    smartliubo1 starred dotnet/orleans
  • 00:21
    ReubenBond synchronize #6996
  • 00:13
    ReubenBond assigned #6999
  • 00:13
    ReubenBond opened #6999
  • Feb 26 20:27

    ReubenBond on master

    Configure MemoryGrainStorageOpt… (compare)

  • Feb 26 20:27
    ReubenBond closed #6993
  • Feb 26 19:14
    cstief starred dotnet/orleans
  • Feb 26 18:54
    benjaminpetit synchronize #6993
  • Feb 26 17:55
    gkze starred dotnet/orleans
  • Feb 26 10:43
    e-jlion starred dotnet/orleans
  • Feb 26 10:07
    wstaelens starred dotnet/orleans
  • Feb 26 04:45
    michaelsg commented #4012
  • Feb 26 04:43
    michaelsg commented #4012
  • Feb 25 19:31
    veikkoeeva commented #6968
  • Feb 25 19:31
    veikkoeeva commented #6968
  • Feb 25 18:22
    benjaminpetit closed #6894
  • Feb 25 18:22
    benjaminpetit commented #6894
  • Feb 25 18:13
    benjaminpetit commented #6976
  • Feb 25 18:03
    benjaminpetit commented #6921
Veikko Eeva
@veikkoeeva
Looking at DB and if the transactions are actually closed or what's happening should help.
About transactions...
Reuben Bond
@ReubenBond
@nathan5580 regular EF transactions will not flow across grains. If it is somehow possible to serialize the EF transaction scope, then you could make it work - but I doubt that it is, since you would have one transaction spanning multiple client connections, which I believe is out of scope for EF transaction scopes
(Note that if they are serializable, then you would likely want to pass them via RequestContext)
Veikko Eeva
@veikkoeeva

I remember discussing here in Gitter with that grey haired guy about using transaction scopes like

using (TransactionScope scope = new TransactionScope())
{
    await grain1.CallAsync();
    await grain2.CallAsync();
}

Heh, memories. :)

Reuben Bond
@ReubenBond
It would be scary if Orleans automatically flowed all ThreadLocal/AsyncLocal state across machine bounds
Veikko Eeva
@veikkoeeva
It would. :D
Reuben Bond
@ReubenBond
Instead, it provides a mechanism for you to flow such context via RequestContext (which is AsyncLocal)
Spyro
@nathan5580
Ok, thanks for the information.
So it is better not to use transactions between grains/silos.
Reuben Bond
@ReubenBond
Yes, for EF transactions, certainly
Paulo Roberto Ramos de Andrade
@prrandrade
Hello everyone! Is there a way to pass customized information between Silos? My intention is to run a service only on one silo, and if this silo is down, other Silo (and just one other Silo) start this 'shared service', so to speak.
Reuben Bond
@ReubenBond
@prrandrade do you need guaranteed mutual exclusion, or is "best efforts" enough?
Paulo Roberto Ramos de Andrade
@prrandrade
in this case, guaranteed exclusion...
Reuben Bond
@ReubenBond
If you need mutual exclusion, then you could look into creating a leasing system (eg, based on Azure Blog Storage Leases)
Depending on how the service operates, you can also use regular grain persistence to guarantee exclusion
Since a non-primary instance of the service would see an inconsistent state exception when they attempt to write
Paulo Roberto Ramos de Andrade
@prrandrade
but how can I detected that the 'chosen silo' is down, so other silo can bootstrap the service ?
Reuben Bond
@ReubenBond
You can listen for cluster membership changes via IClusterMembershipService, which provides a diffable, awaitable stream of changes via an IAsyncEnumerable
Paulo Roberto Ramos de Andrade
@prrandrade
thank you, Ill see more about this interface
Sunny Li
@sunniejai

Hi there, just wondering, can you have multiple subscribers to a single stream (same streamId and namespace)? Or is it designed to have only one subscriber per streamId + namespace?

If it allows multiple subscribers, are all the subscriber grains guaranteed to receive all the events atleast once if you use the Azure Queue Stream Provider with ImplicitStreamSubscription?

Reuben Bond
@ReubenBond
You can have multiple, @sunniejai
Event Hub is more appropriate than Azure Queues. With EH each subscriber will receive each message.
Sunny Li
@sunniejai
Is there a sample with EventHub streams anywhere?
Sunny Li
@sunniejai
Thank you so much for the quick response!
Just wondering, because I don't think I saw this in the docs anywhere. Does the EventHub provider have the same behavior as the Azure Queue Stream Provider where in case of a failure, messages can come out of order?
Wolfgang Groß
@wgross

Just kidding about Open XA, but I do agree that friendlier integration APIs would be nice. Transactions are very tricky to get right and the currently exposed API is deceptive in its apparent simplicity (just 2 methods!). I still hope we can open source one of the internal implementations

@ReubenBond Does "internal implementation" means that there are impl. of distributed transactions internally at MSFT related to Orleans?

This would be pretty huge. In my current project we are looking at Orleans because we want to scale the backend and also support linux but on the other side we have to have distributed transactions. We want to avoid Sagas because the transactions aren't long running an we don't want to create the 'undo'-actions ourselves. If there would be any guidance/example/idea from MSFT how to appraoch this problem it would be extremly helpful.

Reuben Bond
@ReubenBond
@wgross yes, Orleans has an internal implementation of distributed transactions. I posted some links to two articles above (one a technical report) which describe it.
About the TLS sample there, I was thinking Orleans mTLS settings. But off to other things now.
That too.
Reuben Bond
@ReubenBond
Internal teams configure mTLS, @veikkoeeva
Gutemberg Ribeiro
@galvesribeiro
and Xbox live is down :/
ops, wrong chat
Benjamin Petit
@benjaminpetit
@galvesribeiro it's back :p
Wolfgang Groß
@wgross

@wgross yes, Orleans has an internal implementation of distributed transactions. I posted some links to two articles above (one a technical report) which describe it.

@ReubenBond I understood that this is only for grain state or can for example a SQL server used by a grain participate in this TX?

Roope Kivioja
@RKiviojaAdafy

I might have fallen into some sort of beginner trap, but does anyone know if there are limitations on how you can use null values with Orleans actor interfaces?

This works fine if both properties have a value:

var dto = new ExampleDto
{
    Key = key,  // string
    Value = value // string
};

var result = await actor.GetWithKeyAndValue(dto, continuationToken);

But if 'value' is null, Orleans instantly throws:

System.ArgumentNullException: Value cannot be null. (Parameter 'input')
   at Orleans.Internal.OrleansTaskExtentions.<ToTypedTask>g__ConvertAsync|4_0[T](Task`1 asyncTask)
Gutemberg Ribeiro
@galvesribeiro
@benjaminpetit went to sleep :/
some intern hit the DC power outlet with its feet
:smile:
erikljung
@erikljung

Hi, I'm trying to find some docs about reentrency within a call chain, but https://dotnet.github.io/orleans/docs/grains/reentrancy.html#reentrancy-within-a-call-chain doesn't exactly answer my question (maybe I'm missing something). Consider the following code:

public interface ISomeGrain : IGrainWithGuidKey
{
    Task Write( int id, string content );

    [AlwaysInterleave]
    Task<string> Read( int id );
}

public class SomeGrain : Grain<SomeState>, ISomeGrain
{
    public async Task Write( int id, string content )
    {
        State.Items.Add( id, content );
        await WriteStateAsync();
    }

    public async Task<string> Read( int id )
    {
        if ( State.Items.ContainsKey( id ) == false )
            await Write( id, "whatever" );

        return State.Items[id];
    }
}

When Write is called from within Read will Write be working as not-interleaved? eg. will that call be properly awaited and not flux up the state? From a practical test I did, this seems to work fine. If I'm doing a loop of Write calls in Read and just execute them all with Task.WhenAll then this code will explode. Sorry if I'm getting the terminology wrong here, but I'm fairly new to this.

Benjamin Petit
@benjaminpetit
@galvesribeiro but it shouldn't happen with the mandatory WFH! :p
@RKiviojaAdafy are you sure that this ArgumentNullException is not thrown from your grain code?
Gutemberg Ribeiro
@galvesribeiro
@benjaminpetit #truestory :smile:
Benjamin Petit
@benjaminpetit
@erikljung my morning coffee isn't yet correctly processed, but no, your code is not safe. If I understand correctly, what you want here is to go a grain call to write on the saem grain, so the request will be non reentrant
    public async Task<string> Read( int id )
    {
        if ( State.Items.ContainsKey( id ) == false )
            await this.GetGrain<ISomeGrain>(myKey).Write( id, "whatever" );

        return State.Items[id];
    }
erikljung
@erikljung
@benjaminpetit So, in my example I'm calling Write on the same grain. Do you mean that your example is "safe" and if so is mykeyjust a reference to another grain? I don't 100% follow.
Benjamin Petit
@benjaminpetit
in my example, myKey is the key value of the grain. I believe you could do something like that too: this.AsGrainReference<ISomeGrain>().Write(...)
the objective here is do to a grain call, not a simple call to a function
Reuben Bond
@ReubenBond
@wgross it's separate from SQL txns. I described it a little above.