I have a user who gotten a word file locked (attempting to edit again displays a message in word that the file is locked by another user) after editing and saving...I restarted IIS then the user's PC then the web server...the file is still locked...How can we unlock this file? How can we prevent this from happening...
We are using iTHit Ajax library v1.8.0.1342 and IT Hit WebDav Server v3.7.1780
Per iTHit...The lock is requested by the client applictaion, typically by Microsoft Office. The client application specifies the lock period in its request. The server can either issue the lock for the specified period or for any other period it wants. The lock time is passed back to the client. In your server implementation you can program the lock time in ILock.Lock method implementation.
I used Fiddler and found that Word and Excel specified 3600 seconds and the function on the server adds that to the current GMT time for the lock expiration..
Related
We have a single page web application. One of the functions of the application is to supervise the connection path from the client back to the server. This is implemented with a periodic ajax http request in javascript to the server every 60 seconds. This request acts as a heartbeat.
After a session is started, the server looks for that heartbeat. If it fails to receive a heartbeat request after a reasonable amount of time, it takes specific action.
The client also looks for a response to that heartbeat request. If it fails to receive a response after a reasonable amount of time, it displays a message on the screen via javascript.
We are getting reports from the field where a Chrome version of Edge is failing. Communication between the client and server is apparently failing. The server is seeing those heartbeat requests cease – and taking that specific action. However, the client is not taking the expected action on its side. It’s not displaying the message indicating a failed heartbeat request. It’s almost appears as though the javascript stopped running altogether.
The thing is, though… The customer has reported that if they disable automatic updates to Microsoft Edge the application runs fine. If the checking of updates is allowed to occur, the application eventually fails as described above. Note that this is apparently happening when Edge is just checking for updates - it's already up to date.
Updates are being turned off using several guid-named registry keys at [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate].
Any thoughts?
We have a Vaadin 14 (Flow) application which is fronted by an Apache reverse proxy that integrates with Gluu for authentication using OpenID (mod_auth_openidc).
This is generally working fine, except when users leave their browser open with the application idle for a long time, until the max session time of the OpenID session is reached. The problem is, at that point the Vaadin client keeps trying to send heartbeat requests. This, in combination with this mod_auth_openidc issue, results in state cookies piling up and reaching a limit so that the user has to close her browser before being able to re-login.
I've tried various things (unsuccessfully) in order to get the server to instruct the browser to visit a logout URL when a heartbeat request is received after session timeout (in combination with vaadin.closeIdleSessions=true), but even if it worked it wouldn't be a solution for other browser tabs that may also be open at that time and sending heartbeat requests.
What we really want is to limit the number of times the Vaadin client retries to send the heartbeat requests (say max 3 times) and then just stop sending requests (maybe display a message to re-login).
Is this possible in any way? The current workaround is to disable the heartbeats completely, but this doesn't seem ideal (Vaadin won't detect idle UIs).
The UI instance has a ReconnectDialogConfiguration which includes reconnectAttempts property to control how many times to re-try requests (including heartbeat requests). Default seems to be 10000.
In Vaadin 14 (LTS) this can be set using PageConfigurator.
In Vaadin 18 (latest release) this is done using AppShellConfigurator
Disabling the heartbeats is the way to go. If you need something more nuanced than that, you'll need to make a change (maybe add a configuration option) in how Heartbeats work in Vaadin. Creating a ticket in GitHub could be a good place to start.
My goal is to send an email out every 5 min from my application even if there isn't a browser open to the application.
I'm using FluentScheduler to manage the tasks; which works up until the server decides to kill the application from inactivity.
My big constraints are:
I can't touch the server. It is how it is and I have to work around it.
I can't rely on a client refreshing a browser or anything else along the lines of using client side scripts.
I can't use any scheduler that uses a database.
What I have been focusing on is trying to create an artificial postback.
Note: The server is load balanced, so a solution could use that
Is there any way that I can keep my application from getting killed by the server?
You could use a monitoring service like https://www.pingdom.com/ to ping the server at regular intervals. Just make sure it hits an endpoint that invokes .NET code and not a static resource.
I have a SOAP server/client application written in Delphi XE working fine for some time until a user who runs it on Windows 7 x64 behind a corporate proxy/firewall. The application sends and receives TSOAPAttachment object in the request.
The Problem:
Once the first request from this user is received and processed, the server could not process any request (from any user) successfully coming after this.
The server still response to the request, but the SOAPAttachment of the request
seems corrupted after the first one from this user, that's why it couldn't process the request successfully.
After putting may debug logs to the server, I noticed the TSOAPAttachment.SourceStream in the request's parameter become inaccessible (or empty), and TSOAPAttachment.CacheFile also empty. Therefore whenever trying to use the SourceStream, it will return Access Violation error.
Further investigation found that the BorlandSoapAttachment(n) file generated in the temp folder by the first request still exist and locked (which should be deleted when a request is completed normally), and BorlandSoapAttachment(n+1) files of the following request are piling up.
The SOAP server will work again after restarting IIS or recycle the application pool.
It is quite certain that it is caused by the proxy or the user’s networks because when the same machine runs outside this networks, it will work fine.
To add more mystery to the problem, running the application on WinXP behind the same proxy have no problem AT ALL!
Any help or recommendation is very appreciated as we have stuck in this situation for some time.
Big thanks in advance.
If you are really sure that you debugged all your server logic that handles the attachments to attempt do discover any piece of code that could failed specifically on Windows 7, I would suggest:
1) Use some network sniffer Wireshark is good for this task, make two subsequent requests with the same data/parameters values, and compare the HTTP contents. This analyze should be done both in the client (to see if the data is always leaving the client machine with the same content) and also in the server, to analyze the incoming data;
2) I faced a similar situation in the past, and my attempts to really understand the problem was not well succeed. I did workaround the problem sending files as Base64 encoded strings parameters, and not using the SOAP attachments. The side affect of using Base64 its an increase of ~30% in the data size to be sent, and this could be significant if you are transferring large files.
Remember that SOAP attachments create temp files in the server, and Windows 7 has different file access rules than Windows XP. I don't know if this could explain the first call being processed ant the others not, but maybe there are something related with file access.
Maybe it is UAC (User Access Control) problem under Win 7. Try running the client in win 7 "As Administrator" and see if it is working properly.
We have a web application which does some computing and returns a file to the client. When the computing takes less then 5 minutes everything works fine on IE and Chrome and we get the file but if computing takes more than 5 minutes IE times-out with "Internet Explorer cannot display the webpage" message where as Chrome keeps running and eventually gets the file from the server.
I've tried changing registry settings like KeepAliveTimeout, ReceiveTimeout, ServerInfoTimeout of WinInet but it didn't help. Clicking the Diagnose Connection Problems button shows "Windows received an HTTPerror message: 403 (forbidden) from " message which I think is because it tries to again access the site without credentials and fails. When using fiddler the request terminates with 504 status and show this message "ReadResponse() failed: The server did not return a response for this request." Interestingly I've once observed that even Chrome times-out if Fiddler is running (haven't verified this by re-running though.)
This is an ASP.Net web application using MVC framework.
I've spent considerable amount of time but haven't been able to find a solution for this. Any useful pointers would really be appreciated.
From KB181050
You can usually break down long processes into smaller pieces. Or, the server can return status data to update users about the process. In addition, you can create a long server process that has a messages-based or asynchronous approach so that it returns immediately to the user after the job is submitted, and then notifies the user after the long process is finished.
In other words, create a <div> and fill that <div> immediately with a "processing" value after the request has been accepted by the server. Then, use ajax or javascript to update that same <div> with the result whenever you're finished with processing.