As answered here, its enough to return a Task to make a ServiceStack service method async.
If I manually invoke a Service, as described here, I only have a non-awaitable ExecuteMessage, and no ExecuteMessageAsync. There is, in contrast, a method HostContext.AppHost.ExecuteServiceAsync.
Is there a reason for the lacking ExecuteMessageAsync?
I could do like await Task.Run(() => ExecuteMessage(...)), but it doesn't seem right to me.
Any input would be appreciated!
ExecuteMessageAsync didn't exist because it's not needed or used by any of ServiceStack MQ providers. But I've just added Async versions of the ExecuteMessage APIs to both ServiceStack AppHost and its ServiceController.
This change is available from the latest v5.9.3+ that's now available on MyGet.
Related
I am using curl to publish to maven:
const curlOptions = [
'--silent',
'--output', '/dev/stderr',
'--write-out', '"%{http_code}"',
'--upload-file', fileLocation,
'--noproxy', options.noproxy ? options.noproxy : '127.0.0.1',
'--fail'
];
const curlCmd = ['curl', curlOptions.join(' '), targetUri].join(' ');
const childProcess = exec(curlCmd, execOptions, function (error) {
if (error) {
console.log(chalk.red(error));
}
});
This works for the upload but the artefact gets cached and I cannot get the artefact from curl without going to nexus and running rebuild metadata on the affected artifact.
Can i programmatically invalidate the cache?
To answer your question directly, it should be possible to invalidate cache in later versions of NXRM3 using the REST API and the "/beta/repositories/{repositoryName}/invalidate-cache" endpoint.
It should also be possible to do the same and run the scheduled task (rebuild metadata; /v1/tasks/{id}/run endpoint) though that seems a less desirable route as that is generally used for repair.
You can see more on the REST API in the NXRM3 documentation though the intent of some is that it's self documenting by using the Swagger UI in the application. Note at time of this answer, only those with the nx-admin privilege can access the Swagger UI (though people with proper permission can use the endpoints). You can find the Swagger UI in the Admin section under System -> API.
That being said, I think there's likely something else going on. I don't think it should be necessary to invalidate your cache like that each time. I didn't want to go too far from the question however. I encourage you to look at community.sonatype.com for answers to what else might be going on and ask there if you don't see one.
I've been working on a .NET 4.6.1 Web API project. As part of this project, I need to call another Web API and I want to use the HttpClient to do so.
From my research online, you can't rely on just doing a normal HttpClient within a using clause as it doesn't garbage collect correctly and can lead to memory leaks.
E.g., I'm currently using it as follows:
using (HttpClient client = new HttpClient { Timeout = TimeSpan.FromSeconds(CONTENTFUL_TIMEOUT_IN_SECONDS) } )
{
responseText = await client.GetStringAsync(uri).ConfigureAwait(continueOnCapturedContext:false);
}
But as suggested in other articles from Stack Overflow and others, this leads to memory leaks, and the way around this is to share a single instance of the HttpClient.
E.g., check HTTPCLIENT DESTABILIZING YOUR SOFTWARE and HttpClientHandler/HttpClient Memory Leak.
I'm not sure however how to setup a shared "single" instance of the HttpClient from within an WebAPI itself?
You should have a look on how to implement singleton pattern. Refer to this.
Then you can create a singleton of HttpClient and make it responsible for all HTTP calls from your API.
I'm looking at the core-CreateNewConversation sample in the Bot builder examples repo (https://github.com/Microsoft/BotBuilder-Samples). There is a method available on IDialogStack called PollAsync that seems to be gone after version 3.5.0 of bot builder. Is there a reason for this?
In reality, it was just moved from the IDialogStack class to the IDialogTask class.
Instead of doing:
IDialogStack stack = stack = scope.Resolve<IDialogStack>();
you have to do
IDialogTask task = scope.Resolve<IDialogTask>();
then you can just do:
task.Call(interruption, null);
await task.PollAsync(token);
There is a pull request that is updating the sample taking into account this change.
I have a SignalR hub and two clients (Windows and PCL for Android and iOS). Neither of the clients is able to call some methods on the server. This behaviour is quite odd, since the methods look very similar. Moreover, a colleague of mine is able to call methods I cannot call, and vice versa, does not invoke methods that I invoke with no problems.
Here is an example of a method, which works for me and does not work for my colleague:
public override async Task<bool> RefreshArray(User user, int waitMilis)
{
var cts = new CancellationTokenSource();
try
{
cts.CancelAfter(waitMilis);
await Proxy.Invoke("RefreshArray", user);
return true;
}
catch (Exception ex)
{
OnExceptionOccured(ex);
return false;
}
}
And a method which does not work for me, but works for my colleague:
public override async Task<bool> RequestInformation(User user, Product product, int waitMilis)
{
var cts = new CancellationTokenSource();
try
{
cts.CancelAfter(waitMilis);
await Proxy.Invoke("RequestInformation", user, product);
return true;
}
catch (Exception ex)
{
OnExceptionOccured(ex);
return false;
}
}
Yes, me and my colleague have exactly the same code. And no, there are no typos or different arguments. I have tried to get as much data from the client connection as possible, by setting _connection.TraceLevel = TraceLevels.All; However, I did not get any information on the invoked methods, just on the replies from the hub. When calling RefreshArray, I got exactly the data I requested. When calling RequestInformation, the debugger never even hit the breakpoint in the hub method and the _connection.Trace displayed only this: 11:22:45.6169660 - 7bc57897-489b-49a2-8459-3fcdb8fcf974 - SSE: OnMessage(Data: {})
Has anybody solved a similar issue? Is there a solution?
UPDATE 1
I just realized that I have encountered almost the same issue about a year ago (Possible SignalR bug in Xamarin Android). StackOverflow has also pointed me to a question with almost the same issue (SignalR on Xamarin.iOS - randomly not able to call Hub method), just related to iOS and Azure. However, I got the same proble even outside Xamarin, on Windows Phone 8.1 and and Windows 10 Universal App. Moreover, I am running the server just locally, so it is not an issue od Azure. Is it really possible, that a 2 years old bug has no solution?
UPDATE 2
I have just created a simple console application with SignalR.Client. In the console application every method worked just fine. Amazingly, also the Windows 10 Universal Application started to behave as expected - every hub method was invoked correctly. Windows Phone 8.1 also improved its behaviour (all hub methods invoked). However, every now and then the connection tried to reconnect periodically (for no apparent reason), leading to Connection started reconnecting before invocation result was received. error. The Android application still behaved as before.
So I tried to replicate my previous steps and created another console application, but this time with SignalR.Client.Portable library. To my dissapointment, there was no change in the Android application behaviour.
Next week we will start to test our application on iOS, so I really wonder what new oddities will we encounter.
I have managed to solve the problem (at least so it seems). As it turned out, there is some weird stuff going around, when an application receives an answer from SignalR hub. It seems as if the HubProxy was blocked for a certain period of time on Android, while it drops the connection and starts to reconnect periodically on Windows Phone, not waiting for an asnwer from the hub.
The implementation of RefreshArray on the hub was something like this:
public async Task RefreshArray(User user)
{
await Clients.Caller.SendArray(_globalArray);
await Clients.Caller.SendMoreInformation(_additionalInfo);
}
Because the method sent two methods as an answer, the client Proxy got stuck and each platform handled it in its own unexpected way. The reason why some methods were called on my computer and not on colleagues was, simply, because we had different position of breakpoints, which enabled the application to resolve at least some requests and responses.
The ultimate solution was to add some synchronization into the invokation of methods. Now my hub calls only await Clients.Caller.SendArray(_globalArray);. This is then handled on the client with a ArraySent(string[] array) event, which then subsequently invokes the SendMoreInformation() method on the hub.
I'm trying to setup MiniProfiler on my web api site, and having a hard time getting MiniProfiler.Current to work.
I followed the directions at miniprofiler.com, and have the following in global.asax:
protected void Application_Start()
{
MiniProfilerEF6.Initialize();
// other setup
}
protected void Application_BeginRequest() {
// need to start one here in order to render out the UI
MiniProfiler.Start();
}
protected void Application_EndRequest() {
MiniProfiler.Stop();
}
This uses the default WebRequestProfilerProvider, which stores the actual profile object in HttpContext.Current.Items.
When I ask for MiniProfiler.Current, it looks to HttpContext.Current.
When I make a request for one of my web api URLs:
Application_BeginRequest creates the profiler, store it in HttpContext.Current
in a web api MessageHandler, I can see HttpContext.Current
in a web apu IActionFilter, HttpContext.Current is now null, and my attempt to MiniProfiler.Current.Step("controller:action") fails
my EF queries run from various services do not get recorded, as that miniprofiler hook relies MiniProfiler.Current, which relies on HttpContext.Current, which is null right now
Application_EndRequest fires, and HttpContext.Current is magically back, and so it wraps up the profiler and tells me how long it's been since the request began
I dug through the code, and I can create my own IProfileProvider, to store the profiler object somewhere more reliable than HttpContext.Current, but I don't know where that could be.
I spent a few hours trying things out, but couldn't find a workable solution. The problems:
the IProfileProvider is a global variable; all worker threads in either the MVC or Web API pipeline all have to use the same IProfileProvider
I can dig around in web api RequestContext.Properties to pull out the HttpContext for that request, but that doesn't really help because my IProfileProvider is global across the entire app; If I tell it to store the profile in HttpContext A, then any simultaneous requests for other HttpContexts are going to pollute the profile
I can't rely on any kind of threadstorage because of async/await re-using threads dynamically
I can't stick the profiler object in an Ninject binding with InRequestScope because InRequestScope doesn't seem to work with web api 2.1, but even if I could
everyone says HttpRequestMessage.Properties is the new HttpContext.Current.Items, but again, IProfileProvider is a global variable and I don't know of a way to ensure each request is looking at their version HttpRequestMessage. MiniProfiler.Current can be called from anywhere, so I guess a global IProfileProvider would have to somehow inspect the call stack to and find an HttpRequestMessage there? That sounds like madness.
I'm at a loss. What I really want is a special variable.
The process of putting the question together I figured it out. HttpContext.Current can get lost when you async/await things: Why is HttpContext.Current null after await?
I had to make the web.config change listed there, and adjusted my filters to use Miniprofiler.Current before any awaiting.
Also discussed at https://www.trycatchfail.com/2014/04/25/using-httpcontext-safely-after-async-in-asp-net-mvc-applications/