I am having a problem while calling a webService using HttpClient from my another webservice hosted in the same server.
The Scenario is, There is a REST webService, Lets Say "WebService1" that receives the request from multiple clients to create the PDF.
The WebService1 further calls the another webservice "BackendWebService" to create the PDF Doument. This backend WebService references the third party Library to create the PDF.
What is happening now is if a single user calls the WebService1 with 10 requests, then there is no problem. All the requests are processed successfully.
But if there are involvement of multiple users and sends the request to WebService1 simultaneously, then only few records are processed successfully, some of the records are
terminated in middle. It seems the code is not executed completely and the application is terminated without completing the whole process.
Why this is happening ? Please help. I have already created only one static instance of HttpClient, but still no Luck.
WebService1 calls the BackendWebService as below:
for each number of PDF request from client:
This is how WebService calls the BackendWebService
Finally i got the reason of this issue.
There was an concurrency issue in the library (a custom library called processhandler.dll ) referenced in BackendWebService while writing log in to the txt file by multiple processes. And when there is an exception in this referenced library, the process was terminating without any information in IIS or in application level logs as well.
Related
Description: queue the multiple requests for ASP.NET Core 6 Web API.
There are multiple terminals/clients pc to call Web API which triggered the code which is responsible for printing to execute and send out the print command with object to be printed to a printer.
As there are many printers are available but if any one printer is in use means if one request is printing on 1 printer then other request should not proceeds and wait till first request will finish printing and then it will take another request and process for printing like this.
Do we have any suggestion for building this approach?
I have tried this approach https://michaelscodingspot.com/c-job-queues/ but its not working as while adding request in thread it will loose the this.DBContext object.
I found that puppeteer sharp is best way for server side, HTML to PDF conversion as it uses and downloads latest chrome and runs headless in background so the conversion is top class. tables and all else is rendered perfectly.
However for running on server, how should the concurrency be managed, because i think each web site users conversion request will launch another chrome instance. how does puppeteer sharp manages concurrency.
is is better to split it as separate web service and enqueue conversion requests and pass all pdf related requests to be served on one by one basis instead of running into concurrency or resource issues on webserver for multiple chrome instances.
I found this is the most scalable way to implement this is by using a background process. This is one real-life example:
A WebClient request a PDF sending a signalR message.
The SignalR hub creates some kind of an ID, put the request in an Azure Queue, and adds the SignalR client to a SignalR group with that ID.
A console app would read that queue, process the HTML, and sends back the result to the server using a SignalR message.
The WebServer will get the message, and broadcast that message to all the clients in that group.
It might sound quite complicated, but it's not that much. You can make it simpler.
I have a WCF server which is working with database. It is working in single instance and multiple threads mode. Almost every method represents a simple operation to database. On the client side there are many WCF-channels (proxies) which are created at the same time (of course I have various 'lock's when creating a new channel) in multiple threads and as the result I have many concurrent connections (in one client process) to one service.
After some quantity of these calls to the server, my client process crashes. It is not an unhandled exception, the application just crashes and exits. The moment of the crash is not determined. With the help of 'procdump.exe' I have found that it is crashed with StackOverflow after a lot of AccessDenied.
I guess the problem is in WCF messaging queue on the client process side but I cannot solve it. Any ideas?
I am currently working on a project which I think using soap as part of it would be a good idea but I can't find how it will work in the way that I need.
I have a C# Console Application called ConsoleApp, ConsoleApp will also have a PHP web interface. What I'm thinking of doing, is the PHP web interface controls the ConsoleApp in some way, so I click a button on the web interface, then this does a sends a soap request to a soap service and then the soap service, sends the information on to the consoleApp, and the result is returned back to the SoapService and then returned back to PHP.
This seems like it would need to separate soap services, one for php to interface with and one within the ConsoleApp but this doesn't sound right, I think I might be misunderstanding the purpose of Soap.
How can this be achieved. Thanks for any help you can provide
UPDATE
As requested I thought I'd add a bit more information on what I am trying to achieve.
In the console app, it is acting as an email server sending out emails that are given to the program and then being sent on, and if it can't send it retries a couple of times until the email goes into a failed state.
The web interface will provide a status of what the email server is doing, i.e. how many emails are incoming, how many are yet to be processed, how many have sent and how many have failed.
From the web page you will be able to shutdown or restart the email server or put one of the failed emails back into the the queue to be processed.
The idea is, when the user adds a failed email back into the queue it sends a soap message that the console app will receive, add the information back into the queue, log the event in the console apps log file, increment a counter which is how it keep track of emails that need to be processed. Once this has been done it should then send a response back to the web interface to say whether or not the email was successfully added back into the queue or whether it failed for some reason.
I don't really want to keep on polling the database every so many seconds as there could be the potential for their to be a large number of emails that will be being processed so polling the database would put a large load on the MySQL server which I don't want, which is why I thought soap as the email server would only need to do something when it receives a soap request to do something.
Thanks for any help.
Every web service is going to need a client (in your case PHP) and a server (ConsoleApp). Even though there are two endpoints, it is still one web service. Your PHP will send a SOAP request which ConsoleApp will receive, process and respond to with a SOAP response.
So when someone clicks the button on the web page, you can use JavaScript to build and send the SOAP envelope in the browser. The alternative is to POST the values to a PHP page that will build and send the SOAP.
I have to admit though, your scenario sounds a unusual. I personally haven't heard of web pages talking directly with console apps. Web pages usually talk to web servers, and the servers are usually the ones issuing atypical requests, like your request to ConsoleApp. While it is technically possible, but I think it is going to be harder then you are expecting.
Personally, I would ditch SOAP in favor of a much more simple and scalable solution. Assuming you have access to a database, I would have the PHP create a record in the database when the user clicks the button. ConsoleApp would then poll the database every X seconds to look for new records. When it finds a new record, it processes it.
This has the benefit of being simple (database access is almost always easier than SOAP) and scalable (you could easily run an arbitrary number of ConsoleApps to process all of the incoming requests if you are expecting heavy loads). Also, neither the PHP page nor the ConsoleApp have a direct dependency on the other so each individual component is less likely to cause a failure in the whole system.
I'm looking to create a web service and accompanying web app that uses an async web service call. I've seen plenty of suggestions on how to do async calls but none seem to fit exactly what i'm trying to do or are using a really outdated tech. I'm trying to do this in ASP.net 3.5 (VS2008)
What i need to do is:
the webpage needs to submit a request to the service
the page then needs to poll the service every 5 seconds or so to see if the task has completed
once complete the request needs to be retrieved from the service.
Could someone give me some suggestions or point me in the right direction?
The way I have typically handled asynchronous server-side processing is by:
Have the webpage initiate a request against a webservice and have the service return an ID to the long-running transaction. In my case, I have used Ajax with jQuery on the client webpage and a webservice that returns data in JSON format. ASP.NET MVC is particularly well suited for this, but you can use ASP.NET to return JSON string in response to a GET, or not use JSON at all.
Have the server create a record in a database that also stores the associated data to be processed. The ID of this transaction is returned to the client webpage. The service then sends a message to a third service via a message queue. In my case, the service was a WCF service hosted in a Windows Service with MSMQ as the intermediary. It should be noted that it is better not to do the actual task processing in ASP.NET, as it is not meant for requests that are long-running. In a high demand system you could exhaust available threads.
A third service receives and responds to the queued message by reading and processing necessary data from the database. It eventually marks the database record "complete".
The client webpage polls the webservice passing the transaction record ID. The webservice queries the database based on this ID to determine if the record is marked complete or not. If it is complete, it queries for the result dataset and returns it. Otherwise it returns an empty set.
The client webpage processes the webservice response, which will either contain the resulting data or an empty set, in which it should continue polling.
This just serves as an example, you may find that you can take shortcuts and avoid doing processing in a third service and just use ASP.NET threads. But that presents it's own problems, namely how you would have another request (the polling request) know if the original request is complete. The hackish-solution to that is to use a thread-safe collection in a static variable which would hold a transaction ID/result pair. But for that effort, it really is better to use a database.
EDIT: I see now that it appears to be a demonstration rather than a production system. I still stand by my above outline for "real-world" situations, but for a demo the "hackish" solution would suffice.
Which part are going to need to do async ? As far as I can tell your actions are synchronous:
1) -> 2) -> 3)
A simple web service would do, IIS (as any web server) supports multiple request to be handled async so you have no problem.
Something which you may need to be aware of. And also the javascript engine executes code in a single thread.
Step 0: Create the web service.
Step 1: Create the web app project (assuming it's ASP.NET).
Step 2: Add a web reference to the webs service to your web app project.
Step 3: The reference would create a proxy for you, using which you can invoke both synchronous and asynchronous calls.