dotnet / orleans Goto Github PK

Many times we do some work and then do an external service call (or even a grain call) that we would like to process once it returns, but in the meantime, we'd like end the current turn. Once the response comes back, it's be nice to execute the continuation as a full new turn.

Currently it's easy to do things like

someClient.ExecuteIoCallAsync().ContinueWith(this.MyCustomContinuation)

In order to end the turn but then execute the continuation... nevertheless the continuation, albeit running in a single thread in the grain, can interleave with other turns. So in order to workaround that, we sometimes have to do a grain call to tself in the callback, so that it executes as a new request and doesn't interleave. This workaround is not that trivial and still prone to errors, ignoring the fact that you have to "pollute" the public-facing grain interface with the internal details of how we deal with continuations.

Wouldn't it be nice to do something like this instead?

UPDATE: In this thread the code evolved a lot, and we are currently discussing something that doesn't use await. I'd encourage you to look at the updated gist instead: https://gist.github.com/jdom/6597e183eabd3251f4bd

public async Task MyPublicGrainMethod()
{
  // do some async work in the "1st turn"
  await this.SomethingThatNeedsToRunDuringTheGrainCall();

  // now start the async call that I don't want to await during the grain call, but I want the continuation to run in a full turn.
  var myIoTask = someClient.ExecuteIoCallAsync();
  var response = await myIoTask.ConfigureAwaitInNewTurn(endCurrentTurn: true);
  // use response here in a "2nd" turn. Notice that interleaving might have happened by this time, but given you are using ConfigureAwaitInNewTurn, you should know that this is an advanced scenario and be aware of the consequences, such as using closures or ackowledging that state might have mutated by now.
}

I made that example verbose, so that we can discuss ideas... I don't know if it's even possible to end the turn abruptly in the middle of the method, as the task returned by MyPublicGrainMethod might not be completed yet (or can the await logic complete that task instead?, that'd be ideal).

I'm all ears and open to feedback, as this is a simplification of a scenario we use a lot.

2nd topic of the "Ideas for Contributions" list
https://github.com/dotnet/orleans/wiki/Ideas-for-Contributions

Hi.

Running AzureWebSample I always get AzureSilos worker role recycling, with following trace.

Any suggestion?

Microsoft.WindowsAzure.ServiceRuntime Information: 100 : Role environment . INITIALIZING
Microsoft.WindowsAzure.ServiceRuntime Verbose: 500 : Role instance status check starting
Microsoft.WindowsAzure.ServiceRuntime Verbose: 502 : Role instance status check succeeded: Ready
Microsoft.WindowsAzure.ServiceRuntime Information: 100 : Role environment . INITIALED RETURNED. HResult=0
Microsoft.WindowsAzure.ServiceRuntime Information: 101 : Role environment . INITIALIZED
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\WindowsAzureTelemetryEvents\v4.0_2.5.0.0__31bf3856ad364e35\WindowsAzureTelemetryEvents.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\WindowsAzureEventSource\v4.0_2.5.0.0__31bf3856ad364e35\WindowsAzureEventSource.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\Progetti\orleans\Samples\AzureWebSample\OrleansAzureSample\csx\Debug\roles\OrleansAzureSilos\approot\Orleans.Azure.Silos.WorkerRole.dll'. Symbols loaded.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.WindowsAzure.ServiceRuntime\v4.0_2.4.0.0__31bf3856ad364e35\Microsoft.WindowsAzure.ServiceRuntime.dll'. Cannot find or open the PDB file.
Microsoft.WindowsAzure.ServiceRuntime Information: 200 : Role entrypoint . CALLING OnStart(): Microsoft.WindowsAzure.ServiceRuntime.DefaultEntryPoint
Microsoft.WindowsAzure.ServiceRuntime Information: 202 : Role entrypoint . COMPLETED OnStart(): Microsoft.WindowsAzure.ServiceRuntime.DefaultEntryPoint
The thread 0x33a8 has exited with code 259 (0x103).
A first chance exception of type 'System.Threading.WaitHandleCannotBeOpenedException' occurred in mscorlib.dll
Microsoft.WindowsAzure.ServiceRuntime Information: 203 : Role entrypoint . CALLING Run(): Microsoft.WindowsAzure.ServiceRuntime.DefaultEntryPoint
Microsoft.WindowsAzure.ServiceRuntime Warning: 204 : Role entrypoint . COMPLETED Run() ==> ROLE RECYCLING INITIATED: Microsoft.WindowsAzure.ServiceRuntime.DefaultEntryPoint
Microsoft.WindowsAzure.ServiceRuntime Information: 503 : Role instance recycling is starting
The thread 0x3954 has exited with code 259 (0x103).
Microsoft.WindowsAzure.ServiceRuntime Information: 205 : Role entrypoint . CALLING OnStop(): Microsoft.WindowsAzure.ServiceRuntime.DefaultEntryPoint
Microsoft.WindowsAzure.ServiceRuntime Information: 205 : Role entrypoint . CALLING OnStopping()
Microsoft.WindowsAzure.ServiceRuntime Information: 206 : Role entrypoint . COMPLETED OnStop(): Microsoft.WindowsAzure.ServiceRuntime.DefaultEntryPoint
The thread 0x2db8 has exited with code 259 (0x103).
'WaWorkerHost.exe' (CLR v4.0.30319: DefaultDomain): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: DefaultDomain): Loaded 'C:\Progetti\orleans\Samples\AzureWebSample\OrleansAzureSample\csx\Debug\roles\OrleansAzureSilos\base\x64\WaWorkerHost.exe'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: WaWorkerHost.exe): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_64\msshrtmi\v4.0_2.5.0.0__31bf3856ad364e35\msshrtmi.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: WaWorkerHost.exe): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.WindowsAzure.ServiceRuntime\v4.0_2.5.0.0__31bf3856ad364e35\Microsoft.WindowsAzure.ServiceRuntime.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: Domain 2): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.WindowsAzure.ServiceRuntime\v4.0_2.5.0.0__31bf3856ad364e35\Microsoft.WindowsAzure.ServiceRuntime.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: WaWorkerHost.exe): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\mscorlib.resources\v4.0_4.0.0.0_it_b77a5c561934e089\mscorlib.resources.dll'. Module was built without symbols.
'WaWorkerHost.exe' (CLR v4.0.30319: WaWorkerHost.exe): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime\1.0.0.0__31bf3856ad364e35\Microsoft.ServiceHosting.Tools.DevelopmentFabric.Runtime.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Core\v4.0_4.0.0.0__b77a5c561934e089\System.Core.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Xml.Linq\v4.0_4.0.0.0__b77a5c561934e089\System.Xml.Linq.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Xml\v4.0_4.0.0.0__b77a5c561934e089\System.Xml.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_64\System.Web\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Web.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_64\msshrtmi\v4.0_2.5.0.0__31bf3856ad364e35\msshrtmi.dll'. Cannot find or open the PDB file.
Microsoft.WindowsAzure.ServiceRuntime Information: 100 : Role environment . INITIALIZING
Microsoft.WindowsAzure.ServiceRuntime Information: 100 : Role environment . INITIALED RETURNED. HResult=0
Microsoft.WindowsAzure.ServiceRuntime Information: 101 : Role environment . INITIALIZED
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\WindowsAzureTelemetryEvents\v4.0_2.5.0.0__31bf3856ad364e35\WindowsAzureTelemetryEvents.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\WindowsAzureEventSource\v4.0_2.5.0.0__31bf3856ad364e35\WindowsAzureEventSource.dll'. Cannot find or open the PDB file.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\Progetti\orleans\Samples\AzureWebSample\OrleansAzureSample\csx\Debug\roles\OrleansAzureSilos\approot\Orleans.Azure.Silos.WorkerRole.dll'. Symbols loaded.
'WaWorkerHost.exe' (CLR v4.0.30319: RdRuntime): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.WindowsAzure.ServiceRuntime\v4.0_2.4.0.0__31bf3856ad364e35\Microsoft.WindowsAzure.ServiceRuntime.dll'. Cannot find or open the PDB file.
Microsoft.WindowsAzure.ServiceRuntime Information: 200 : Role entrypoint . CALLING OnStart(): Microsoft.WindowsAzure.ServiceRuntime.DefaultEntryPoint
Microsoft.WindowsAzure.ServiceRuntime Information: 202 : Role entrypoint . COMPLETED OnStart(): Microsoft.WindowsAzure.ServiceRuntime.DefaultEntryPoint
The thread 0x3290 has exited with code 259 (0x103).
A first chance exception of type 'System.Threading.WaitHandleCannotBeOpenedException' occurred in mscorlib.dll
Microsoft.WindowsAzure.ServiceRuntime Information: 203 : Role entrypoint . CALLING Run(): Microsoft.WindowsAzure.ServiceRuntime.DefaultEntryPoint
Microsoft.WindowsAzure.ServiceRuntime Warning: 204 : Role entrypoint . COMPLETED Run() ==> ROLE RECYCLING INITIATED: Microsoft.WindowsAzure.ServiceRuntime.DefaultEntryPoint
Microsoft.WindowsAzure.ServiceRuntime Information: 503 : Role instance recycling is starting
The thread 0x2a7c has exited with code 259 (0x103).
Microsoft.WindowsAzure.ServiceRuntime Information: 205 : Role entrypoint . CALLING OnStop(): Microsoft.WindowsAzure.ServiceRuntime.DefaultEntryPoint
Microsoft.WindowsAzure.ServiceRuntime Information: 205 : Role entrypoint . CALLING OnStopping()
Microsoft.WindowsAzure.ServiceRuntime Information: 206 : Role entrypoint . COMPLETED OnStop(): Microsoft.WindowsAzure.ServiceRuntime.DefaultEntryPoint

@yevhen and @kspeakman expressed some ideas for a better approach to unit testing grains. Let's discuss the ideas here.

One way to support Bond is to allow to use it optionally in addition to the built-in Orleans-generated serializers, similar to custom serializers. That way code that already uses Bond could work with Orleans.
The solution will probably need to add a message header to indicate serializer used
Will be less automatic than the built-in option but compatible with non-.NET clients
Explore other ways to use Bond.

Worker role for silos (in our experience it is better to star a silo as a standalone process and wait on the process handle in the worker roles code)
Worker/web role for frontend clients
Configuration of diagnostics, ETW tracing, etc.
Try Azure SDK plug-in as suggested here by @richorama.

Could I suggest pointing the http://aka.ms/orleans link to this repo now?

(also - on an unrelated note) I see there is a 1.0.0 branch, is this a release branch? Where can I get the installer for that? (codeplex is still on 0.9)

...and the CI server is returning a 404 :¬(

I have a few scenarios where the grain state needs to be indexed, so it is possible to either lookup a grain by something else other than the primary key.

One of those examples would be trying to implement an Orleans Provider for ASP Identity. For example GetUserByName and GetUserByEmail I also have a few domain specific scenarios as well.

The way I am currently approaching this, (which most likely not the best way but it is working at the moment on a simple level) is I am saving the UserEntity to ATS along with saving the Index Properties to ATS as well.

I then have a stateless grain which does the lookup of ATS to find the index I want, which then allows me to get the UserGrain by the Id.

It seems rather cumbersome way of getting the grain (but it works), however I was reading an old research paper "Orleans: Cloud Computing for Everyone" which talks about a Queryable attribute.

Annotations on grain interface members, such as Queryable, are used by the developer to cause Orleans to generate additional methods on the factory class for searching for grains that satisfy specified conditions.

Does a feature like this exist in the current build?

I have been pondering other ways to lookup and index which could cut down the network traffic from hitting ATS, so another thought I had was to have a grain to manage the lookup for each index. So call the lookupGrain which then had a reference to the actual grain I wanted.

It would be great to get any input on what thoughts there are around best practice in regard to looking up a grain by different properties within the state.

Hi.

What is the right way to build SDK so that setting OrleansSDK evnironment variable everything works as with 0.9 SDK installer?

Will you provide precompiled SDK too (either on Codeplex site or on GitHub)?

Thanks!

There are a number of attribute combinations which doesn't make sense to mix together. For example: mixing StatelessWorker with any of Placement attributes doesn't make sense, but it looks like currently it is allowed to combine them within same class declaration.

I'm not sure what will happen in this case and I guess that handling code is smart enough to just ignore placement attributes if used along with StatelessWorker. Nevertheless, I found it to be confusing and I think it might be better to fail with exception to prevent users polluting grain declarations with useless combinations of attributes, which will confuse all future readers. Also, such validation should prevent users from cargo-culting Orleans.

Other invalid combinations:

• Mixing attributes from same category - looks like now I can put both RandomPlacement and ActivationCountBased or PreferLocal. Which one will Orleans choose?
• Reentrant could be mixed with AlwaysInterleave - seems like another confusing combination. Grain is either fully reentrant (class-level attribute) - all methods are subject to interleaving, or only some individual methods allow interleaving.

Another, possible and probably more intuitive approach will be, is to group all choices under respective category attributes (and use AllowMultiple=false), to make alternation explcit. Something like:

• Activation - Singleton / StatelessWorker
• Concurrency - Strict / Reentrant
• Placement - Random / PreferLocal / ActivationCountBased
• Delivery - Ordered / Unordered
• etc

What do you think?

We're evaluating Orleans for suitability in an upcoming project, it certainly ticks a lot of boxes for us.

One sticking point at the moment though is around current project status and where it might go from here.

1. How close are we to a 1.0 release?

• What is left to do before 1.0?
• Given the above, were we to adopt 0.9 now, how much friction do you anticipate in moving to 1.0

2. What is the Road Map for the framework?

• Once 1.0 is out, where does the project go from here?
• Are there plans to continue pushing it forward or is it your intention to hand it over to the community?

Thank in advance.

Existing test assemblies are intended to test Orleans public APIs. This is good, but leaves no place to write tests for internal components.

Suggest adding another test assembly “TesterInternals” for testing Orleans internals.

Add a queue balancer (IStreamQueueBalancer) which uses the deployment configuration to determine how many silos to expect and uses a silo status oracle to determine which of the silos are available. It should use this information to balance the queues with the following requirements.
• Even distribution of resources across silos
• Minimize movement of resources when rebalancing from changes in active silos.
• Must be deterministic independent of previous queue distribution state.

This is work that didn't make it in prior to moving depot to github.

Since http://aka.ms/orleans url has been re-pointed to GitHub repo the CodePlex link in Installation page is wrong:

You can get the installer from the Orleans Codeplex site.

The link should be updated to http://orleans.codeplex.com.
I do not have permissions to update wiki so I log this issue instead.

As projects move forward requirements change and code ends up being refactored, this could as simple as a namespace being changed, or Oect1Grain being renamed to Object2Gain etc..

What is the recommend way of handling state when this happens? as my understanding from looking at how the state is stored, the grain type is linked to the state record (for example in Azure Storage it becomes the RowKey). Which would imply that refactoring/renaming the grain or namespace would break the reading of the previous state when the service is updated.

One possible solution could to be to add an attribute to the grain (like we do with the storage provider) which allows us to specify the Type as string to override the default type that would be provided enabling backwards compatibility with old state?

I'd would be interested to hear how others are approaching the scenario, or point out something I may have missed.

I have come across another small bug in the CodeGen which prevents using IGrainObserver in being used with VB

Adding the following interface to the GrainInterfaces project creates a compile error.

Public Interface IMyObserver
        Inherits IGrainObserver

End Interface

The code generated that is invalid is

Public Shared Sub DeleteObjectReference(reference As onShowcase.Distributed.GrainInterfaces.ApplicationData.IMyObserver) As System.Threading.Tasks.Task
            Return Global.Orleans.Runtime.GrainReference.DeleteObjectReference(reference)
End Sub

It is declaring a sub/void but then trying to return a task.

It is caused by

We added a page with some initial ideas for contributions. Let's use this issue for discussing the list and adding to it. Please create separate issues to discuss individual ideas/features.

Currently the default placement strategy is rather hardwired and limited and it is only possible to tweak it using the built-in placement strategies. I'd like to propose that we open up PlacementDirectorsManager, PlacementStrategy, and PlacementDirector so grain solutions can opt to create their own placement strategies for more specialised setups. Simultaneously, it would be beneficial to be able to specify a custom default placement strategy in the configuration and have that take effect globally rather than having to go through all the grains and add attributes to them.

Some of the custom placement strategies that might be of interest could be to limit new activations to not overwhelm a fixed machine setup (e.g. in a non-cloud/non-virtual setup), place activations according to expected communication coherence, etc.

At the moment GitHub does not provide discussion forums functionality. Since the project is moving out of CodePlex, consider creating a mailing list (Google Groups or similar) to have a place where people can ask questions, give feedback and get support from the community.

P.S. StackOverflow could be another possible alternative.

In order to get AzureWebSample working (although it is likely that same should be done to deploy any Orleans applications on Azure environment), it seems that several Orleans components have to be updated to correct dependencies from Azure SDK 2.5.

Please refer to #67 for details.

LRU.cs#L113.Add

The problem for :LRU.cs#L193

Before I go and write the code for this, I thought it would be worth having the discussion.

Current design

Presently the scheme for the PartitionKey / RowKey fields on OrleansSiloStatistics is as follows:

PartitionKey: SiloName:Date
RowKey: DeploymentId:Epoch:counter

For example:

PartitionKey: 17b8149c37384e16aa5672193dc8daa1:2014-08-15
RowKey: S100.74.190.62:11111:145792311:000001

Problems

Table storage can only return values in the alphabetical order of the partition/row keys. It would be nice to have the keys laid out such that a simple query (just fetch 1000 entities from the table) always retrieves the latest records written to the system.

A technique for doing this is documented here: http://blog.smarx.com/posts/using-numbers-as-keys-in-windows-azure

It would also be nice to have a deterministic way of retrieve the data, without knowing the machine names, i.e. just supply a date range to retrieve all data in that period.

Suggested solution

My suggestion is this format:

PartitionKey: Date:SiloName
RowKey: EpochCountdown:DeploymentId:counter

Where EpochCountdown is a padded string, counting down the seconds to the end of the epoch.

Note that the order of the keys has also been changed.

PartitionKey: 2014-08-15:17b8149c37384e16aa5672193dc8daa1
RowKey: 854207689:S100.74.190.62:11111:000001

Impact

This technique gives you a date-first approach to reading the data, and makes it harder to query by a single machine.

I would have to make some adjustments to my SiloMon project!

Otherwise, I'm not sure how widely used this table is?

Other thoughts

Is colon : the best character to use as a separator? It's a character used by the silo name. Perhaps using a dollar $ would be better?

Take OrleansR by @richorama - https://github.com/OrleansContrib/OrleansR and develop it into a robust feature. Or redo it from scratch differently if there is a better idea.

After installing Microsoft.Orleans.Client or Microsoft.Orleans.Server NuGet packages configuration files is not appeared in project folder.

It seems they are in not appropriate folder (lib\net45 instead of content).

Current name of the NuGet packages is ProjectOrleans.xxx.

Consider renaming it to Orleans.xxx or Microsoft.Orleans.xxx.
The word project in the package name doesn't seem to add any value and won't help with powershell auto-completion (orl + TAB).

I'm happy to update all the nuspec files

targets and props files are not included to the project after installing
Microsoft.Orleans.Templates.Interfaces or Microsoft.Orleans.Templates.Grains packags.

Based on NuGet documentation(http://docs.nuget.org/create/creating-and-publishing-a-package#import-msbuild-targets-and-props-files-into-project), .target and .props files should be named as {packageid}.targets and {packageid}.props accordingly.

Parameters which use language keywords as their name are not correctly escaped by current code generation, which causes compilation failures.

For example, this will cause generated code to fail to compile:

public interface IReproGrain : IGrainWithIntegerKey
{
  Task Repro(int @event, bool @new, string @class);
}

A bunch of early adopters have run into this issue (serves us right for calling parameters "event" 😝)

Mostly just s/HelloWordGrains/HelloWorldGrains/ but also affects namespaces, directory names and project names.

PR incoming...

I'd like to discuss an addition of a uniform communication interface, which has potential for seriously improving Orleans' interoperability, extensibility and ease-of-use for a number of advanced scenarios.

Not as simple as changing NuGet package names but I think this should be discussed before wider adoption. Those are breaking changes and it's better to bite the bullet now.

I would like to suggest we change Orleans dlls \ exes to Microsoft.Orleans.xxx. and change the namespaces accordingly.

What are your thoughts?

It would be very helpful if we are able to update the Tools and SDK with the VS Extension manager.

Currently there are 3 IMembershipTable implementations, a "development only" grain-based implementation, an Azure Table Storage implementation, and a SQL Server implementation.

I want to be able to reliably bootstrap silos without relying on SQL Server or Azure Table Storage.

It would be great if we could have a model for injecting custom IMembershipTable implementations.

This one is not documented anywhere but is visible on API's public surface.. It' also the only one which targets grain interface (all other attributes target grain implemenation classes).

What does it do?

please give a code way to boostrap silo

 var BOOTSTARTP_PROVIDER_CONFIGS_NAME = "Bootstrap";
            ProviderCategoryConfiguration providerConfiguration;
            if (!siloHost.Config.Globals.ProviderConfigurations.TryGetValue(BOOTSTARTP_PROVIDER_CONFIGS_NAME, out providerConfiguration))
            {
                providerConfiguration = new ProviderCategoryConfiguration()
                {
                    Name = BOOTSTARTP_PROVIDER_CONFIGS_NAME,
                    Providers = new Dictionary<string, IProviderConfiguration>()
                };
            }

            var eventStoreProvider = new ProviderConfiguration(new Dictionary<string, string>(), typeof(EventStoreInitBootstrapProvider).FullName, "EventStoreInitBootstrapProvider");
            providerConfiguration.Providers.Add("EventStoreInitBootstrapProvider", eventStoreProvider);

            siloHost.Config.Globals.ProviderConfigurations[BOOTSTARTP_PROVIDER_CONFIGS_NAME] = providerConfiguration;

but failed. I read the source code ,find some class have method like AddProvider ,but internal

please give a way to give the Application Bootstrap by code.

The source code builds properly, however, when I run "InstallOrleansVSTools.cmd", it fails to find what it needs or there is a permission problem is what it reports(see pic).

Since that failed, I installed the VSIX manually, but the Hello World sample fails to build.

I originally tried this in VS2012, but got the same results in VS2013 on a different machine.

6. Migrate and update samples from Codeplex [Small/Medium] from Ideas for Contributions

@sergeybykov @gabikliot - could you please provide some guidance on where the samples should be placed and what kind of updates should be made?

I am getting the error below when I compile one of my iGrain interfaces.

Error   6   'Orleans.GrainFactory.Friend Shared Function Cast(Of TGrainInterface)(grain As Orleans.Runtime.IAddressable) As TGrainInterface' is not accessible in this context because it is 'Friend'.  C:\Users\Benjamin\Documents\Visual Studio 2013\Projects\KeynotelyOrleans\Keynotely.GrainInterfaces\GeneratedFiles\orleans.codegen.vb    1689    190 Keynotely.GrainInterfaces

What appears to be the trigger of this error is if I pass an iGrain in to a parameter of a function in the iGrain interface.

For example:

Function SaveIndexAsync(grainType As String, propertyName As String, propertyValue As Object, grainReference As IGrain) As task

The GrainFactory isn't exposing the Cast function, where as GrainFactoryWith*****Key all expose the cast, for example if I updated my code to:

Function SaveIndexAsync(grainType As String, propertyName As String, propertyValue As Object, grainReference As IGrainWithStringKey) As task

It will compile fine, I am not sure if this a bug, or is by design - any input or thoughts are welcome.

Auto-generated documents can help provide more complete and up-to-date documentation with little effort.

I'm thinking first steps might be.

1. Select code generator - Doxygen?
2. Create basic configurations and script to generate reference manual like documentation.

Then we can refine the comments in code to improve the generated documents.

When generated documentation is of sufficient quality we can:
3) Incorporate document generation into the builds.
4) Add automation to publish documents online whenever repository is updated.

Thoughts?

See #10
For example:
ActivationID.cs
GrainID.cs
(note upper-case D in file name, but not in class name)

I have a class in which is make up of a set of properties just to store data data, when I but that as a parameter or result in a grain interface the class library fails to build.

for example Function FindByEmailAsync(email As String) As Task(Of UserDataEntity)

I am currently using VB, when I look at the errors it is failing because the generated code (orleans.codegen.vb) it is a mix of VB and C#.

The generated class the errors appear in is the '*_UserDataEntitySerialization' and appears in the functions DeepCopier, Serializer and Deserializer.

For example the following is generated:
Dim temp21 As Object = CType(Orleans.Serialization.SerializationManager.DeepCopyInner(fieldInfo21.GetValue(input)),Action<Object,OperationContext,IDictionary<String,EntityProperty>>)

But I would assume it should be something like:
Dim temp21 As Object = CType(Orleans.Serialization.SerializationManager.DeepCopyInner(fieldInfo21.GetValue(input)), Action(Of Object, OperationContext, IDictionary(Of String, EntityProperty)))

Or I am doing something totally wrong, if so happy to be guided in the right direction.

Currently, we are exposing codegen'd factory classes for IGrainObservers (there may be others, please add them here).

We should create a generic factory which provides access to the codegen'd factories and hide the concrete implementation.

This will help us with Dependency Injection and give us the flexibility to use runtime codegen (eg, via Roslyn)

Orleans client currently uses a Guid to uniquely identify itself when connecting to a gateway silo.
In addition, there is also a notion of client grain id that is used to identify client. There is some redundancy between those two. This issue to fix that, by eliminating the Guid client id and using Client Grain id to uniquely identify that client.
This fix is a first part of the bigger work on improving client observers.

When using the SqlServer system store, the reminders service fails to read from the database during silo startup. It looks like the hash value changed from int to uint between the preview and 1.0 release, however, SQL Server doesn't natively handle unsigned datatypes.

[2015-01-24 17:51:45.973 GMT     8            ERROR  102920  ReminderService             127.0.0.1:11111]               !!!!!!!!!! Failed to read rows from table. 
Exc level 0: System.ArgumentException: No mapping exists from DbType UInt32 to a known SqlDbType.
   at System.Data.SqlClient.MetaType.GetMetaTypeFromDbType(DbType target)
   at System.Data.SqlClient.SqlParameter.set_DbType(DbType value)
   at Orleans.Runtime.ReminderService.SqlReminderTable.<ReadRows>d__a.MoveNext() in H:\Orleans\src\OrleansRuntime\ReminderService\SqlReminderTable.cs:line 73
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Orleans.Runtime.ReminderService.LocalReminderService.<ReadTableAndStartTimers>d__2d.MoveNext() in h:\Orleans\src\OrleansRuntime\ReminderService\LocalReminderService.cs:line 268

While I can perfectly load OrleansConfiguration using

new OrleansConfiguration().Load(new StringReader(embeddedResourceFile));

The ClientConfiguration does not provide this method in it's public interface, so currently I'm using this filthy hack:

var loader = result.GetType().GetMethod("Load", BindingFlags.Instance | BindingFlags.NonPublic, null, new[] {typeof(TextReader)}, null);
loader.Invoke(result, new object[]{LoadFromEmbeddedResource(assembly, fullResourcePath)});

Also, I think renaming OrleansConfiguration to 'ServerConfiguration` will add consistency and perfect symmetry (Client/Server). The principle of "no surprises" - is a hallmark of a good API =))