In liferay 6.2 we need to communicate to a Web service at the time of the user login and the call is expected to be asynchronous, i.e. the user login continues without being impacted from the web service call (even in case of remote exception).
I am not sure where I can plug the call to this web service. I tried with:
1. User Model Listener = > It halts until the remote call is finished (I added the call at #onBeforeUpdate and #onAfterUpdate )
2. User login post action => It halts until the remote call is finished.
I read about the messaging implementation for async calls, is this the only way forward, or can there be a simpler approach that I am overlooking?
Thanks!
There is no out-of-the-box async method in Liferay that you can use - only synchronous methods. However, if the web service that you call is implemented asynchronously, it wouldn't halt the execution of your Liferay hook. You'll have to check with your webservice's implementation why it blocks execution when it shouldn't (as you say "it's expected to be asynchronous").
Related
I have a following issue regarding using WCF service from my ASP .NET mvc application. Service requires a callback method to be implemented on the client side. For that I am using wsDualHttpBinding. Callbacks are being invoked and the correct info is recieved (checked using brakepoints multiple times).
The issue lies in the fact that I'm not able to save the data that I recieve when callback "SendComment" is invoked from WCF service. Callback method definition:
public void SendComment(ChatComment cc)
{
Session["Message"] = cc;
}
This is a method that should allow client (in asp .net) to recieve chat messages that are broadcasted to multiple clients from WCF service.
When I try to access Session["Message"] from the controller methods, it's value is null after I have recieved a callback. This is the main problem. I have to find a way to save the value for it to be available in current session context.
Additionally i can't access any of the other session variables I have saved right before the callback is invoked. They are always null.
Besides how do I know when I've recieved the callback? Do I have to use event handlers or somehow call the controller/view from this method?
I've already tried googling for the answer but none of the solutions explicitly state how to access the value after callback has happened.
P.S. Sessions are set to required in WCF Service.
This will not work the way you designed it. A few reasons why not:
You cannot access session from callback.
You cannot call client directly from ASP.Net MVC application.
You have too look for some other solution. I suggest you look into SignalR or if you need something simpler use DB to store data and pool from client.
I have a silverlight app running in a browser as part of an overall ASP.NET website. I'm doing some event logging from it (tracking some UI click events and such).
I have a WCF service set up to create DB log records, and obviously the Silverlight app is calling it asynchronously.
This all works just fine, until I try to fire off a call to the logging service at the tail end of the app life. That is, when the user clicks a certain button, the silverlight calls some javascript on the website to redirects to another page, so the silverlight app closes, and then only sometimes do the last logger calls get through.
I am assuming it has something to do with the shutdown procedure of silverlight, and that it is a timing issue whereby sometimes the WCF channel is still open and the message gets through, and sometimes the channel closes and the logging doesn't occur.
Regardless of whether or not the logging occurs, the callback never fires for this last logger call.
As part of the handler for the last closing click event, the silverlight app calls this:
System.Windows.Browser.HtmlPage.Window.Eval("ViewEmployersPageWithMenu();")
Which, as I understand it, will trigger an exit of the silverlight app as the browser is navigating away from it.
Just before doing this, I fire off a simple logger call to my async wCF service.
I believe silverlight doesn't allow async service calls during its exit handling, is this the case? If there a different way I should be handling this o get that log call out successfully before the app closes?
If the logging is that important and considered an integral part of the application, you could hold off on calling the JavaScript function until the callback of the logging request. It may cause some delay in the execution of the redirect as it is now waiting for the WCF request to round-trip, but perhaps that is preferred to missing the log.
If you can replicate the issue, I would be curious to how Fiddler sees the series of requests (logging request and redirect request) when it works compared to when it does not. That may show that the browser is canceling the log request when it executes the redirect.
We are making a web service call on some data updates to sync another database. This web service call takes up some response time. Would adding it in a thread help at all? Any downfalls of doing this? If the web service calls fails, it fails and that is it. It is like a fire and forget call.
You could use an Asynchronous Web Service call using asyncronous callbacks to prevent blocking of your main thread.
By making an asynchronous call to a Web service, you can continue to
use the calling thread while you wait for the Web service to respond.
This means users can continue to interact with your application
without it locking up while the Web service access proceeds.
From MSDN: Making Asynchronous Web Service Calls
If it's taking long enough to hang the user interface then calling it on another thread is the recommended thing to do.
In addition to Tudor's answer I would suggest that you start off by using the new Task class from .NET 4.0.from task parallel library. Example would be:
Task backgroundProcess = new Task(() =>
{
service.CallMethod();
});
I strongly advice against using Async Web Service calls (including making calls in separate threads) from a web app. Instead use alternate approach like Ajax, and make this webservice call from an Ajax Call instance. There is no easy approach in the web context to handle threading and Async calls.
We have an application that hits a web service successfully, and the data returned updates our DB. What I'm trying to do is allow the user to continue using other parts of our web app while the web service processes their request and returns the necessary data.
Is this asynchronous processing? I've seen some console app samples on the msdn site, but considering this is a web form using a browser I'm not sure those samples apply. What if the user closes the browser window mid request? Currently we're using the Message Queue which "waits" for the web service to respond then handles the DB update, but we'd really like to get rid of that.
I'm (obviously) new to async requests and could use some help figuring this out. Does anyone have some code samples or pertinent articles I could check out?
Yes, what you're describing is async processing.
The best solution depends to some degree on the nature of the web services call and how you want to handle the results. A few tips that might help:
One approach is to send a request from the initial web request to a background thread. This works best if your users don't need to see the results of the call as soon as it completes.
Another approach is to have your server-side code make an async web services call. This is the way to go if your users do need to see the results. The advantage of an async call on the server side is that it doesn't tie up an ASP.NET worker thread waiting for results (which can seriously impair scalability)
Your server-side code can be structured either as a web page (*.aspx) or a WCF service, depending on what you want to have it return. Both forms support async.
From the client, you can use an async XMLHTTP request (Ajax). That way, you will receive a notification event when the call completes.
Another approach for long-running tasks is to write them to a persistent queue using Service Broker. This works best for things that you'd like users to be able to start and then walk away from and see the results later, with an assurance that the task will be completed.
In case it helps, I cover each of these techniques in detail in my book, along with code examples: Ultra-Fast ASP.NET.
If you're not blocking for a method return you're doing asychronous processing. Have a look at Dino Esposito's article on using AJAX for server task checking.
You can perform asynchronous web service calls using both Web Service Enhancements (WSE) and Windows Communication Foundation (WCF) in your C# code. WSE is discontinued, so its use is not recommended. Generically speaking, if you were to terminate program execution in the middle of an asynchronous call before the response returned, nothing bad would happen; the client would simply not process the result, but the web service would still be able to perform its processing to completion.
If your client web application is responsible for updating the DB, then without anything else in your client code, quitting in the middle of an asynchronous operation would mean that the DB was not updated. However, you could add some code to your client application that prevented the browser from quitting entirely while it is waiting for an asynchronous response while preventing new web service calls from being run after Close is called (using Javascript).
You have 2 distinct communications here: (1) from web browser to web application and (2) from web application to web service.
diagram http://img697.imageshack.us/img697/6713/diagramo.png
There is no point of making (2) asynchronous: you still would have to wait for web service to finish processing request. If you end HTTP request from browser to web application the client would have no clue what the result of request was.
It is much better to make asynchronous request from web browser to your web application. Ajax is ideal for that. In fact, that's what it was created for. Here's couple of links to get you started:
jQuery Ajax
ASP.NET AJAX
What is the difference between Web Services Asynchronous Call and Asynchronous Task's.
We are working an a ASP.NET application that requires to make a call to a Web Service Method that will process thousand rows of data. This process usually takes between 2 to 3 minutes (maybe more maybe less it depends of the amount of Data). So we run all the time in Timeout's on that specific page.
So we decided to go in rout of calling this Web Service Method Asynchronously, but we had a conflict caused by HTTP handler of one of the UI component's that we are using. Well lucky on that case we could remove the page from the httphandler directives.
So far no issues, but here it comes the question, a coworker find out that we can use instead of Asynchronous Webs Services Call, wrap a Synchronous call in a Asynchronous Task in the ASP.NET page and be able to keep the directives to the component, and execute the Web Service Method with out getting a Timeout.
So now my concern is what kind of issues we can find using Asynchronous Task's instead of an Asynchronous Call.
Thank you in advance.
Web services should not be used in this manner by the way. There's a reason HTTP timeouts are so low. You should have the Web service trigger the task either by setting a flag in the DB that an actual service picks up on or the web service should spawn a process.
If I understand your scenario, there should be no issues. In both cases, your page is asynchronous. In both cases, you don't wait for the service to complete - you give up the request thread while the service is running. In both cases, your page takes the same amount of time to execute as it would if you had called the service synchronously.