We use actions-on-google library:
<dependency>
<groupId>com.google.actions</groupId>
<artifactId>actions-on-google</artifactId>
<version>1.8.0</version>
</dependency>
Our flow includes calling HomeGraphApiServiceGrpc.requestSyncDevices(RequestSyncDevicesRequest request) to Synchronize our devices when something has changed.
Our testers noticed that some requests return StatusRuntimeException and it appears more and more often now.
How can we minimize the occurrence of such an error and what causes it may have?
Looks like you might be going above the rate limits for the HomeGraph API (applicable to REST & RPC APIs). Alternatively, there are two ways to issue request sync: synchronous (blocking) and asynchronous. If you are having issues with one of those types, you can try out the other.
Related
I am currently working on a web service in Go that essentially takes a request and sends back JSON, rather typical. However, this particular JSON takes 10+ seconds to actually complete and return. Because I am also making a website that depends on the JSON, and the JSON contents are subject to change, I implemented a route that quickly generates and returns (potentially updated or new) names as placeholders that would get replaced later by real values that correspond to the names. The whole idea behind that is the website would connect to the service, get back JSON almost immediately to populate a table, then wait until the actual data to fill in came back from the service.
This is where I encounter an issue, potentially because I am newish to Go and don't understand its vast libraries completely. The previous method that I used to send JSON back through the HTTP requests was ResponseWriter.Write(theJSON). However, Write() terminates the response, so the website would have to continually ping the service which could now and will be disastrous in the future
So, I am seeking some industry knowledge into my issue. Can HTTP connections be continuous like that, where data is sent piecewise through the same http request? Is that even a computationally or security smart feature, or are there better ways to do what I am proposing? Finally, does Go even support a feature like that, and how would I asynchronously handle it for performance optimization?
For the record, my website is using React.js.
i would use https websockets to achieve this effect rather than a long persisting tcp.con or even in addition to this. see the golang.org/x/net/websocket package from the go developers or the excellent http://www.gorillatoolkit.org/pkg/websocket from gorilla web toolkit for use details. You might use padding and smaller subunits to allow interruption and restart of submission // or a kind of diff protocol to rewrite previously submitted JSON. i found websocket pretty stable even with small connection breakdowns.
Go does have a keep alive ability net.TCPConn's SetKeepAlive
kaConn, _ := tcpkeepalive.EnableKeepAlive(conn)
kaConn.SetKeepAliveIdle(30*time.Second)
kaConn.SetKeepAliveCount(4)
kaConn.SetKeepAliveInterval(5*time.Second)
Code from felixqe
You can use restapi as webservice and can sent data as a json.SO you can continously sent data over a communication channel.
I noticed on one of Scott Hanselman's blogs he uses the following code in his Views when using .Net 5 (MVC 6):
#await Html.PartialAsync("_LoginPartial")
vs.
#Html.Partial("_LoginPartial")
Is there any documentation yet on when which one should be used?
This is actually a pretty interesting question and scenario. To a certain extent, async is the new hotness (though it's really not all that new). Entity Framework 6 hit with async methods and every... single... piece... of... documentation... suddenly starting using async for everything. I think we're seeing a little of the same here. MVC 6 supports async for things like rendering partials, so OMG we've all just have to use async now.
Async serves one very specific purpose. It allows the active thread to be returned to the pool to field other tasks while the current task is in a wait state. The key part of that is "wait state". Certain tasks are just flat out incompatible with async. CPU-bound work like complex financial analysis never allows the thread to enter a wait state so everything is effectively run as sync even if you set it up as async. On the other hand, things involving network latency (requesting a resource from a web API, querying a database, etc.) or that are I/O bound (reading/writing files, etc.) can at times have periods where the thread is waiting around for some other process to complete before it continues processing.
Looking specifically at rendering a partial, the only piece that's not entirely CPU-bound is reading the view file itself from the filesystem. While that's technically enough to make it eligible for async, how long is it really going to take to read what's essentially a text file that's probably less than 50KB max. By the time the thread is handed back to the pool, it's probably time to request it back, so you're actually using resources more inefficiently at that point.
Long and short, don't fall into the trap of "it can be done async, so I must do it async". Each use should be evaluated in terms of whether there's actually value in it. Async has a lot of overhead, and if you're only talking about a few milliseconds of wait time, it's probably not worth all that extra overhead.
As per the ASP.NET MVC documentation on partial views.
https://docs.asp.net/en/latest/mvc/views/partial.html
The PartialAsync method is available for partial views containing asynchronous code (although code in views is generally discouraged):
Also the note on the page.
If your views need to execute code, the recommended pattern is to use a view component instead of a partial view.
So you should use Partial and avoid PartialAsync, and if you find yourself with a PartialAsync you should question yourself whether you're doing something wrong, maybe you should be using a ViewComponent instead or move the logic from the view to the controller.
Just to keep the thread up to date for those visiting in the age of asp.net core.
Currently, according to the documentation:
Partial and RenderPartial are the synchronous equivalents of PartialAsync and RenderPartialAsync, respectively. The synchronous equivalents aren't recommended because there are scenarios in which they deadlock. The synchronous methods are targeted for removal in a future release.
Full content:
Partial views in ASP.NET Core
To get an idea about why this is an issue, you can take a look at this github entry:
https://github.com/aspnet/Mvc/issues/7083
But long story short it looks like the synchronous version of Partial simply calls async one with GetResult and that's a recipe for deadlocks in some scenarios.
To sum up, there is no real reason not to use the Async version. There are reasons not to use the sync ones.
Even though there is little chance to actually run into deadlocks without huge load and fancy logic within the views.... But if you do, it will be terribly hard to debug and fix.
var result = htmlHelper.RenderPartialAsync(partialViewName, htmlHelper.ViewData.Model, viewData: null);
result.GetAwaiter().GetResult();
With regards to "await Html.PartialAsync" - this link may help you - http://aspnetwebstack.codeplex.com/workitem/601 (follow the comments too) (as to what exactly was the problem before).
I am working on a public facing website being built on MVC 6 and "await Html.PartialAsync" is faster than "Html.Partial" - especially when the view contains lot of components.
Taking out the "await" out of Html.PartialAsync does not obviously work and Html.PartialAsync spits out the type name (ie, "System.Threading.Tasks.Task`1[Microsoft.AspNet.Mvc.Rendering.HtmlString]") instead of the actual view.
Necromancing.
Option 1:
Your child partial view has some async await code in Razor markup - it might deadlock since MS code just calls GetAwaiter().GetResult() and that's a recipe for deadlocks.
Use PartialAsync
Option 2:
Your partial view does not have any awaits but your model-grneration code does (for example Html.Partial("MyView.cshtml", new MyModel { PropertyX = await XyzXyz() }) then it might also deadlock.
Use PartialAsync
Option 3:
Your partial does not use async/await whatsoever, all the way down.
It's OK to use Html.Partial (sync)
I'm using Northscale 1.0.0 and need a little help getting it to limp along for long enough to upgrade to the new version. I'm using C# and ASP.NET to work with it using the Enyim libraries. I currently suspect that the application does not have enough connections per the socketPool setting in my app.config. I also noted that the previous developer's code simply treats ANY exception from an attempted Get call to MemCache as if the item isn't in the cache, which (I believe) may be resulting in periodic spikes in calls to the database when the pool gets starved. We've been having oddball load spikes that don't seem to have any relation to server load. I suspect that he is not correctly managing the lifecycle on the connections to Northscale and that we are periodically experiencing starvation in the socket pool as a result, but I'm unable to prove it.
Is there a specific exception I should be looking for when I call the Get method to retrieve items from cache? I'm not really seeing much in the docs that gives me sufficient information on this. Anybody have any sample code on this? I'd even accept java or php code, as I think the .NET libraries were probably based on one of those anyway.
Any ideas?
Thanks,
Will
If you have made the connection correctly to the membase server(formerly Northscale) typically you only get an exception on 'get' when it's not a hit.
I'm trying to implement the advice found in this great blog post for batch processing in grails with MySQL. The problem that I'm having is that inclusion of periodic calls to session.clear() in my loop causes org.hibernate.LazyInitializationException's to be thrown. There's a quote down in the comments section of the page:
You’re second point about potentially
causing LIEs is absolutely true. If
you’re doing other things outside of
importing with the current thread,
you’ll want to make sure to reattach
any objects to the session after
you’re doing your clearing.
But how do I do that? Can anyone help me specifically understand how to "reattach any objects to the session after I'm done clearing?
I'm also interested in parallelizing the database insertion process so that I can take advantage of having a multi core processor. Can anyone provide advice on how to do that in Grails?
Grails has a few methods to help with this (they leverage hibernate under the covers).
If you know an object is detached, you can use the attach method to reconnect it.
If you've made changes to the object while it was detatched, you can use merge.
If for whatever reason, you're not sure if an object is attached to the session, you can use the link text method to find out if it is or isn't.
It might also be worth reviewing the Hibernate documentation on Session.
I have a sequential workflow with a number of Activities. One of these activities needs to access my paid S3 account. It works fine, but to be cautious, I would like to make sure it can handle unexpected situations, such as 'Host not found' or some timeout, etc.
So .. i would normally put the code inside a TRY / CATCH. That's fine .. but i'm not sure of what i should do with the workflow .. because if the code fails to complete correctly, the rest of the workflow shouldn't occur (based on the logic of this workflow).
So, i wanted to maybe retry the connect a few times .. and if that finally fails, call an Email Activity and terminate workflow.
Can anyone make any suggestions, links to vid's or screenies that help show what is the best practice for this?
cheers!
You might also want to have a look at this blog article on a custom Retry activity:
http://www.pluralsight.com/community/blogs/matt/archive/2007/11/28/49315.aspx
Looks like it is just what you might need!
Take a look at the FaultHandlerActivity, which is used to handle an Exception of the type specified by the FaultType property. Some links about error handling in WF:
Fault Handling in Workflows
Using the FaultHandlerActivity Activity
Exception and Error Handling (partial book chapter)
Another way is to use the Activity.HandleFault method, which is called when an exception is raised within the context of the execution of your activity.