Lets say we have a log file (preferably a txt file) available in the web server. How can we put it online and update it constantly like for every minute. Also, how can we create a script in which it will fetch the log file every minute, analyze its contents and perform some tasks.
It should be enough to publish it in a web server folder.
By this i mean It is possible to write this file and publish it to either an ftp connection or on the web server itself if you have access to this.
I'll be happy to provide more details if you tell me which way you prefer to go :)
The best approach here is to create/write a bash file, cron job or script. The contents will be following the logic : copy the file towards the public web folder every minute.
for client analyzing the log file. one way is to also create a cron job with the following logic: fetch the new log file, then perform analysis (for example, if it found the word "stopped", then some action will be taken like restarting the process/application) and some action. repeat this for every minute
Related
I am trying to build my first ever API and I want it to read some text from a .txt file.
I wrote the code originally to have the text be stored in memory and then remove it after the HTTP Get request. I had it working properly when I would run it in Visual Studio, so I decided to deploy it to Azure. I would then make the HTTP request to add more text into the memory and then I would essentially request it back, however I wouldn't get the text I wanted back. Instead I would get my error message saying that there is nothing in the list which holds the text I want.
I then decided to have it write the text to a .txt file then receive it from that. Once again this worked on my side, but once I published the code to Azure and send a request, I get a 500 Internal Server Error.
At the end of this long story is my question since I can't seem to find any details about .txt files on an Azure Web server.
Is it possible to have my C# class's in my Models folder of my API Web app read a .txt file on an Azure server?
Is it possible to have my C# class's in my Models folder of my API Web app read a .txt file on an Azure server?
The short answer: yes.
The slightly longer answer: yes, however...
As posted in the comments reading and writing information to and from a file in a web application can go bad really fast. Think about two users trying to write at the same time, one user reading at the moment another one is writing and so on.
Now I can imagine the only thing you want to do right now is test to see if it works, so multiple users might not be on top of mind. But even a proof of concept deserves the correct approach, since you might learn something the wrong way otherwise.
Have a look at storing your information in a data store inside Azure, there are quite a few options. For this just to work, it's probably best to use something that's not too hard to set up like Table Storage. If you run into any issues trying to get this to work, open up a new question and we'll be happy to help.
500 Internal Server Error, these is general error in server side. I reproduce same problem and its working fine by using following steps.
After deploy on Azure its show 500 error.
you find actual error to enable Application Insights and go to Failures tab. You can see actual error why occurred.
Click on Error
See Error and File location.
Check File location, if file not there location then create a file on that location. Go to advance tool
Click to go link.
Select Cmd from Debug console dropdown. and click on Site->wwwroot
Create a txt file
Output : Now its working.
I've written a script in c# which I have to execute on a daily basis. It's something like an updater for my data base. So it pulls some data from the Active Directory using CSVDE, and saves that info into csv files in the same directory, then parses those files and updates my database if necessary. Obviously I don't want to run it manually every day, so instead I added a scheduled task. My problem is that it doesn't create the expected files, at least in the same path. If I run the script manually it works like a charm. Also after a scheduled run I tried to find those files by filename on the machine to check whether those were created in some other place, but no luck.
Do you have any idea why it not works the same way?
It was some issue with the credentials under the script ran. Solved now.
I've developed a service that watches one directory and then if a file is created or changed it will spin up another small c# script that will determine what to do with that file. I need this to be constantly listening to the directory at all times(even on start up of the server) because a file could be generated in this directory at literally any time.
I've searched and tried a few things but each time. The service will run then a file will be generated...then it launches the other C# script and does what it needs to with that file and then the service stops. So next time something happens in that directory nothing happens. Is there something I'm missing? How would I go about doing this?
So, your C# service will be stopped working after the first time that it runs your C# script?
I think it should related to your service configuration.
Checkout these links to see how you should create a service through C# :
http://www.codeproject.com/Articles/3938/Creating-a-C-Service-Step-by-Step-Lesson-I
http://www.codeproject.com/Articles/106742/Creating-a-simple-Windows-Service
http://www.codeproject.com/Articles/400697/WCF-Service-Creation-With-Csharp
I hope it helps you to find your mistake.
(If there's sth else, tell in comment)
I have a web form which takes in user information. The value of various text boxes is used to build a html file. I write this html to a file( with specific name) and then prompt user to Save this file.This html is used for creating outlook email signatures. Currently I have this html within the application.This has been deployed to the server. I had to set write permission on this file for all users for it to work.
Are there any security risks? What happens if multiple users access this applications and write to the file at the same time.
When you say the file has "a specific name", do you mean that it is always the same name? If so, then yes, there will be problems if multiple users use this functionality at the same time. They'll be overwriting the one file and downloading each other's data. You would need to generate a unique filename each time the process runs to avoid this.
But do you actually need to save the file?
Or is your goal purely to produce some HTML for the user to download, and the way you are doing this is by writing it to a file, and then prompting them to download that file?
If you don't need to save the file, but rather just need to generate HTML and prompt the user to save, just serve it up as a normal page, and set response headers such that their browser will download it. Something along these lines:
Response.AddHeader("content-disposition", "attachment;filename=my_file.html");
From what I understand, the user fills the web form and submits. Immediately, an html file pops up for download from the server. I think this is very neat implementation of this scenario. You just need to make sure that resources are released properly in order to prevent locking of files.
When multiple users access this application, it should not break since separate files are created with a specific name (as you have mentioned). I don't know what logic has been used to create unique names. At some peculiar situation (this is purely dependent on your name calculation logic) if the calculated specific file name somehow becomes similar to an existing file, you should have code in place to replace or create a different version of the same file name. Locking could occur if you are writing captured data from web form into the same file again and again without disposing your stream/File objects . Make sure you dispose your objects after use in the code.
It would be great if you give access to the application pool of the web application to a user who has write access to that file/folder instead of giving everyone the write access. In this way, your application gets full rights to perform write operations rather than users having rights. If users have write access on the file/folder, it is very easy for anyone to peek in and do something unexpected.
Hope this helps.
I am developing a website using VS 2008 (C#). My current mission is to develop a module that should perform the following tasks:
Every 15 minutes a process need to communicate with the database to find out whether a new user is added to the "User" table in the database through registration
If it finds an new entry, it should add that entry to an xml file (say NewUsers18Jan2009.xml).
In order to achieve this, which of the following one is most appropriate?
Threads
Windows Service
Other
Are there any samples available to demonstrate this?
Separate this task from your website. Everything website does goes through webserver. Put the logic into class library (so you can use it in the future if you will need to ad on-demand checking), and use this class in console application. Use Windows “Scheduled task” feature and set this console app to run every 15 minutes. This is far better solution than running scheduled task via IIS.
It doesn't sound like there's any UI part to your task. If that's the case, use either a windows service, or a scheduled application. I would go with a service, because it's easier to control remotely.I fail to see a connection to a web site here...
Why in the world would an admin need to get pinged every 15 minutes? Poor admin!
I would just put a time stamp on each entry in your users table and create a quick report to allow the admin to query the data whenever they need it.
I think your approach is wrong. You should do one of two things:
Add a user to the XML file as the last step in creating the user.
Generate the XML file on demand when it is requested. This will give you real-time information with very little overhead.
A windows service would give you a good solution - or if you're using SQL Server you could fire this kind of processing from a SQL Agent job.
If you want the code to be 'part' of your web application you could always fire the logic fro a heartbeat page which runs your task(s) whenever the url is called - you can then poll the url from a service or agent job.
The simplest approach is to create a System.Threading.Timer in your app on Application_Start and put it in some static field so it does not get collected. That way you can have your web app poll the database without an external process needed. Of course if your app goes down so does the timer.
For the polling logic just keep a last userId (if you have an increment policy) and check for new added users by filtering WHERE id > lastId.
Create a new table (or text file) that stores the last time you did a "new user export" or additionally just look for the modified/creation date of the last export file. When your script hits your DB do a SQL command to get all users created after the last export time. Spit out new XML for each user.
Set this script to run as a windows scheduled task/cron job/maybe even a database trigger.
Since you seem to be adding all users for a given day to a single XML file (as per your post), why do you need to do this every 15 minutes? Wouldn't it be sufficient to do this once after midnight?
When you do that, preferably in a Windows Service (if it has to run every 15 minutes) or in a command line app that's scheduled to run once at e.g. 0:15 hours, you'll just need to check the "sign up" date for the users and if there's any that signed up the past day, you add them to your list and export that list to the XML file at the end of processing the table.
Marc
While I also voted for creating a Windows Service to perform this function for you, the simplest way I could think to do it would be to put a trigger on your "Users" table that would create the xml file for you when a user is inserted.
I second Chuck's answer - you could pull this data from the database using an XML query and send it directly, no need to much around creating files on the system.