I started using gRPC with Visual Studio 2022 and never saw so many issues as now.
When I wanted to create an additional Proto file I got the error saying that I need to specify the language. That's weird, because I selected the proper option which is designed for C#. So it never worked and I simply had to copy default greeter file.
I created the console app which uses this default greeter service and it even worked. But I added the additional proto and created another fairy simple service and it did not want to compile it referring to some missing types of something. I can't remember the exact error message but I resolved it only by reducing the grpc.* package version to 2.27.I found this answer by googling and I find it weird that Microsoft releases something what does not work in the most simple case scenario.
I decided to test my new test grpc service and created the client:
var channel = GrpcChannel.ForAddress("https://localhost:5001");
var client = new Greeter.GreeterClient(channel);
var reply = await client.MySimpleMethodAsync(new MyRequest { Id = 123 });
Console.WriteLine(reply.Message);
Console.ReadKey();
The MySimpleMethodAsync method is very simple, it just reads the record from the DB using Dapper, nothing special.
Surprisingly there was no compilation error, but when I tried to run it (along with the server app) I got the exception on the line var reply = await client.MySimpleMethodAsync, saying Grpc.Core.RpcException: 'Status(StatusCode=Unimplemented, Detail="Service is unimplemented.")'
I don't understand why it says so. The service is implemented, it's compilable! Googling did not help but I found that other people are having the same issue too.
Eventually I found that if I modify the grpc service and for some reason it does not like it and then I rollback the changes, it's not compilable anymore! I clearn solution, rebuild it - nothing helps! The only thing which helps is addting the brand new project and copy pasting the previous "stable" code.
I've never seen such the ...technology that never works!
Anyway, now the most important issue for me is #3 , why it says the service is not implemented?
Related
To Datastax C# driver engineers:
C# driver 3.3.0 is deadlocking while calling to Connect(). The following code snippet on Windows Forms will deadlock trying to connect:
public void SimpleConnectTest()
{
const string ip = "127.0.0.1";
const string keyspace = "somekeyspace";
QueryOptions queryOptions = new QueryOptions();
queryOptions.SetConsistencyLevel(ConsistencyLevel.One);
Cluster cluster = Cluster.Builder()
.AddContactPoints(ip)
.WithQueryOptions(queryOptions)
.Build();
var cassandraSession = cluster.Connect(keyspace);
Assert.AreNotEqual(null, cassandraSession);
cluster.Dispose();
}
Deadlocking happens here:
Cluster.cs ->
private void Init()
{
...
TaskHelper.WaitToComplete(_controlConnection.Init(), initialAbortTimeout);
...
}
I have tested this on Cassandra 3.9.0, CQL spec 3.4.2 on local machine.
Everything deadlocks on calling this method _controlConnection.Init() here:
task = Id = 11, Status = WaitingForActivation, Method = "{null}", Result = "{Not yet computed}"
This then just runs for 30000ms and throws this:
throw new TimeoutException(
"Cluster initialization was aborted after timing out. This mechanism is put in place to" +
" avoid blocking the calling thread forever. This usually caused by a networking issue" +
" between the client driver instance and the cluster.", ex);
Running same test on 3.2.0 has no such problems. Can anyone else test this? Maybe this just happens to me.
Edit:
Here is the screenshot for the deadlock:
Thanks to the details in your comments, we were able to identify the underlying issue.
Similar to what was proposed by Luke, there were some missing ConfigureAwait() calls.
This issue impacts users that are calling Cluster.Connect() on environments with SynchonizationContext which is not a common use case:
For Windows Forms, its unlikely to communicate directly to a database (without a service in the middle). Furthermore, users should call Connect() before creating a form (where there is no SynchonizationContext) to share the same Session instance across all forms.
For ASP.NET, users should call Connect() outside of any endpoint action, before the HttpContext is created (where there is no SynchonizationContext).
Note that this issue affects only Connect() calls. Other blocking calls like Execute() don't have this issue.
In any case, this issue could be a showstopper for users getting started with the driver, for example, users creating a simple windows forms app to try a concept.
I've submitted a pull request with the fix, which also contains a test that looks into the source code for the usage of await without ConfigureAwait() calls to avoid having this issue in the future:
https://github.com/datastax/csharp-driver/pull/309
You can expect the fix to land in the next patch release.
I can't reproduce the problem, but I suspect the problem might be with a recent change to make the connection process asynchronous internally. I don't know for sure, but tracing through the Connect code, I suspect it might be a missing ConfigureAwait(false). In particular, it looks like the Reconnect method (which could definitely get hit as part of that Init code path) is missing one after that commit. It's possible that I'm not able to reproduce it because I'm not hitting the Reconnect code path while for some reason you are in your environment.
I'm not 100% sure that's the culprit, but I opened a PR to fix it. Stephen Cleary wrote a great explanation on why this can happen in Forms/Web apps. You could try building the driver from my fork to see if that change fixes the problem, or wait and see what happens with the PR and a new release. If it's still happening, I'd suggest opening an issue on the JIRA.
Hope that helps!
Issue has been opened here with workaround:
https://datastax-oss.atlassian.net/projects/CSHARP/issues/CSHARP-579
For anyone experiencing the same - just wrap your connection code into a new task.
Task.Run(() =>
{
SimpleConnectTest();
});
Something strange is happening. I have a WCF service using C# and Visual Studio 2015 up and running.
This service is published to my local IIS and I have a test website where I can consume my services and display results. The website is running in the visual studio IIS on a generated port.
I have a test project which is where I'm experiencing a problem. In the test project I run the same code that works in the website. However when I debug it my wcf result is already out of context.
The test fails
The service result 'does not exist in the current context' when debugging.
[TestMethod]
public void Test_GetListOfFastPlans()
{
FastPlanFileShareServiceClient client = new FastPlanFileShareServiceClient();
ListSharedFastPlansResult thisismyresult = client.ListOfSharedFastPlans("asdf", "asdf", null, null, null, false);
Assert.IsTrue(thisismyresult.ServiceResult.WasSuccessful);
}
I can step through the entire code block from creating the client to making the call and finally the assertion without any errors. however, the resultclass and the client are never in context.
I don't know what is happening or how to diagnosis the issues.
As it turns out I was running in Release mode. When I switched it to Debug mode I was able to get context on my objects and step through the code as expected. I have not researched this in detail, if anyone has a specific reason on why a proxy service does this please add it.
I used proxy in my server And that created a problem.by deleting Proxy problem is solved.
I have several web services residing on a LIVE server that return data to a client. For some reason since I have moved the services from TEST server to the LIVE server the services are breaking.
My logs indicate that the services are executing correctly serverside but on the client side 'nothing' is returned. I.e. the client exists unexpectedly and the local variables defined 'do not exist in the correct context' when debugging.
PDFLive.PDFServiceClient client = new PDFLive.PDFServiceClient();
string[] response = client2.ReceiptPDF("document string");
string foo = "othercodetobeexecuted";
If I debug over this code, it will attempt to execute 'string[] response ...' and then just skip over the other code and end the client without returning any errors or exceptions and making the local variables
string[] response
and
string foo
'Non existent in the current context'
I have enabled Diagnostics in my web.config and they indicate no errors. Again on the serverside the code executes correctly its the return data that isnt reaching the client or reaching the client but not being processed correctly on the client side.
Ive tried creating the default WCF project and deploying it on my LIVE server and consuming it externally alas, same issue. Could it be something on the Server that is disallowing data to be sent?
I have searched high and low but without any meaningful error being returned its difficult to know what the issue could be. Has anyone had any experience with this issue or come across it in anyway?
I can consume the service via an external test client but when adding a service reference to a C# project it displays the behaviour mentioned above.
SOLVED:
I had to uncheck 'optimize' code in the project settings and my debugger works perfectly now. I got the idea from this post A curious case of Visual Studio 2010 debugger
SOLVED: I had to uncheck 'optimize' code in the project settings and my debugger works perfectly now. I got the idea from this post A curious case of Visual Studio 2010 debugger
In my WPF application I want to make a connection with a Web-Service through HTTPS ignoring possible certificate errors, which seems to be a fairly common thing to do, from what I've been researching.
I've found this nifty snippet:
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
I've set a breakpoint on the return statement, and it is never called (tried it with a separate method too).
I've also tried setting the following properties to false:
ServicePointManager.UseNagleAlgorithm = false;
ServicePointManager.Expect100Continue = false; //tried true too
ServicePointManager.CheckCertificateRevocationList = false;
I've also tried to create my own ICertificatePolicy with a CheckValidationResult that always returns true and attributing it to ServicePointManager.CertificatePolicy. That also hasn't worked.
In all of these attempts, I get the following:
The underlying connection was closed: An unexpected error occurred on
a receive
I've created a separate windows forms application with just three lines:
WebReference.MySebService myWebService = new WebReference.MySebService();
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
bool result = myWebService.TestConnection();
//TestConnection is a method in my WebService that simply returns true.
And it WORKED.
What else could I try ?
Info:
WPF application
.NET 3.5
The web-service is consumed through a separate class
It works perfectly with regular HTTP
Not using proxy
Fails both on the server and with the WS on localhost
The same three lines that run on my test app, won't work in my WPF app
The two instances of the WebService are exactly the same (all properties, including URL)
Tried deleting and re-adding the web-reference just as in my test apps.
After stressing a lot about this, we've finally come to a solution.
The hint to it was in the inner-exception, which passed unnoticed before. It stated that it failed to load a Security assembly.
Coincidentally we had a project named Security with an output assembly named Security on this solution, which caused a conflict. And it was only incorrectly accessed when SSL was being used.
Interestingly enough, neither Visual Studio, nor the compiler have warned me that this wasn't such a good idea, and not even that there was a .NET assembly named just like ours.
The solution was to rename this assembly, and everything worked perfectly immediately without a flaw.
Lessons learned:
Use customized names that could never exist already, like
SPONGEBOBSQUAREPANTS_Security.
Do not trust that Visual Studio will check if my assembly is conflicting with anything.
Always check for inner exceptions, no matter how familiar their outer ones may seem.
I am using the Mathematica .Net/Link platform to create a web service to format and calculate math problems. However I am unable to get it working.
I create it using this code:
_Log.IpDebug("Starting the Kernel Link");
if (string.IsNullOrEmpty(_MathLinkArguments))
_InternelKernel = MathLinkFactory.CreateKernelLink();
else
_InternelKernel = MathLinkFactory.CreateKernelLink(_MathLinkArguments);
_Log.IpDebug("Kernel Link Started");
_InternelKernel.WaitAndDiscardAnswer();
The value of _MathLinkArguments is -linkmode launch -linkname \"C:\\Program Files\\Wolfram Research\\Mathematica\\7.0\\Math.exe\".
This piece of code is called from the Application_Start method of the global.asax.cs file.
When it gets to the WaitAndDiscardAnswer() call it gives the server error:
Error code: 11. Connected MathLink program has closed the link, but there might still be data underway.
Note: The SampleCode given with the .NET/Link package (both a console app and a WinForms app) works.
Edit:
I copied the console app sample code given with Mathematica into an asp.net page and it gave me the same error the first load and then on subsequent loads it gave me:
Error code: 1. MathLink connection was lost.
Edit2:
I forgot to mention that when I have procmon and task manager open while running my app, I can tell that Math.exe starts but it immediately exits, which makes those error code make complete sense...but doesn't explain why that happened.
To allow the .Net/Link to work in Asp.net (at least in IIS 7.5) you need to enable the property loadUserProfile on the app pool for the web site.
I am not entirely sure why this is the case, but from what I found while trying to debug this, there are some things that are gotten from the user's profile. I know for a fact that the default location of the kernel is, which explains why I couldn't use it with no arguments, and so I can only assume that other things are needed as well and without the profile it couldn't determine that.
But whatever the reason is this is required, it is, or at least it is a fix if you are getting similar problems like this in your own application.
I got the same error in a .Net WinForm application.
mathKernel = new MathKernel();
mathKernel.Compute("<< XYZ`XYZGraphs`");
The error occurred on loading the package straight after instantiating the MathKernel.
To resolve it you can wait a couple of seconds and then instantiating the MathKernel works fine. During this state where there might still be data underway the following conditions are both false:
if (!MathKernel.IsConnected)
{
MathKernel.Connect();
}
if (MathKernel.IsComputing)
{
MathKernel.Abort();
}
Edit:
I've recieved the error again and this time was able to determine the problem.
Using a command line open the MathKernel.exe and view the error message: