We've been having a PNR subscription for Itinerary Ticketing/time limit Misc ticketing. We've consistently received ENS event for ticketing but stopped receiving update on cancellation since Dec 22nd. We were told by support that our endpoint is sometime unreachable (without any failed request sample) or return status different than 202.
We've assessed our network and it shows a healthy status without any down time. Our logs show that we've responded with 202 for the ENS calls that reached our server.
We're expecting to receive ENS update events on any cancellation as defined in the Sep 2020 ENS Dev guide
Itinerary: "When any itinerary segment data changes (added/deleted/modified)"
While we're waiting for support, I thought I could ask the community if anyone experience the same problem or have any recommendation on where I should look.
Sabre Dev, any pointer you can provide?
Adding a windows shared printer (like \\server\printer) after a spooler service restart (or computer reboot), takes about 45 seconds every single time. This is even after the driver is downloaded. Server is Windows 2016. Client can be Windows 7 or Windows 10. I've tried process monitor, but still can't figure it out. To reproduce:
# as admin (powershell)
restart-service spooler
# as regular user
date
add-printer -connectionname \\server\printer
date
Wednesday, May 2, 2018 10:39:08 AM
Wednesday, May 2, 2018 10:39:51 AM
It turns out the server print spooler service (spoolsv) uses rpc which listens on a dynamic port (49152-65535), and some kind of firewall was blocking it. After a timeout, printing will shift to port 135.
I am really stumped on this one, I have a page that I am using to collect data on what methods are being called in my web application. When I run my application from visual studio, there is no problem, everything works great, all my server and client methods function as expected.
However, when I deploy this application to my webserver running IIS 7.5 on windows server 2008, R2 SP1 my client side methods do not consistently fire, everything looks like its running fine. but the triggering client event never happens.
Client Side Javascript:
var nlog = $.connection.centralHub;
$.connection.hub.logging = true;
$(function () {
var logTable = $("#logTable");
nlog.client.logevent = function (datetime, siteName, clientConId, logLevel, message, stack, eMessage) {
var tr = $("<tr>");
tr.append($("<td>").text(datetime));
tr.append($("<td>").text(siteName));
tr.append($("<td>").text(clientConId));
tr.append($("<td>").text(logLevel));
tr.append($("<td style='white-space: pre;'>").text(message));
tr.append($("<td>").text(stack));
tr.append($("<td>").text(eMessage));
logTable.append(tr);
};
nlog.client.test = function() {
$("#test").text("spit out a test");
}
$.connection.hub.start().done(function () {
nlog.server.initialMessage();
nlog.server.test();
}, 5000);
});
Server Hub methods:
Hub Method: CentralHub
public void InitialMessage()
{
string connId = Context.ConnectionId;
_clientTracker.InitalMessage(connId);
}
internal void InitalMessage(string connId)
{
Clients.All.logEvent(
DateTime.Now.ToString("F"),
"Harper Woods",
connId,
"info",
"Hub Started",
"No Message",
"No Message");
}
Google Console output from my IIS webserver
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Client subscribed to hub 'centralhub'
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Negotiating with '/signalr/negotiate?connectionData=%5B%7B%22name%22%3A%22centralhub%22%7D%5D&clientProtocol=1.3'.
jquery.signalR-2.0.3.js:76
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Attempting to connect to SSE endpoint 'http://tcdev.citadelsystems.com/signalr/connect?transport=serverSentEvents&…7Hb0f69Gs1q&connectionData=%5B%7B%22name%22%3A%22centralhub%22%7D%5D&tid=2'.
jquery.signalR-2.0.3.js:76
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: EventSource connected.
jquery.signalR-2.0.3.js:76
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Now monitoring keep alive with a warning timeout of 13333.333333333332 and a connection lost timeout of 20000.
jquery.signalR-2.0.3.js:76
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Invoking centralhub.InitialMessage
jquery.signalR-2.0.3.js:76
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Invoking centralhub.Test
jquery.signalR-2.0.3.js:76
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Invoked centralhub.InitialMessage
jquery.signalR-2.0.3.js:76
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Invoked centralhub.Test
Google Console Output from Visual Studio 2013
[12:17:56 GMT-0400 (Eastern Daylight Time)] SignalR: Client subscribed to hub 'centralhub'.jquery.signalR-2.0.3.js:76
[12:17:56 GMT-0400 (Eastern Daylight Time)] SignalR: Negotiating with '/signalr/negotiate?connectionData=%5B%7B%22name%22%3A%22centralhub%22%7D%5D&clientProtocol=1.3'.
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Attempting to connect to SSE endpoint 'http://localhost:32568/signalr/connect?transport=serverSentEvents&connectio…kMTNQps1lto&connectionData=%5B%7B%22name%22%3A%22centralhub%22%7D%5D&tid=3'.
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: EventSource connected.
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Now monitoring keep alive with a warning timeout of 13333.333333333332 and a connection lost timeout of 20000.
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Invoking centralhub.InitialMessage
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Invoking centralhub.Test
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Triggering client hub event 'logEvent' on hub 'CentralHub'.
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Triggering client hub event 'test' on hub 'CentralHub'.
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Invoked centralhub.Test
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Invoked centralhub.InitialMessage
Ok, I finally was able to find a bit of information on what is going on here. It is where you set the dependency injection resolver for signalr, this MUST be done in the Application_Start() method of the Global.asax, you cannot rely on ninject web bootstrapper, and you cannot put it in the owin startup class like the example on ASP.NET site. It will not function predictably it will work sometimes, but you will miss messages.
I had this same exact issue. My SignalR Application would work perfectly in Visual Studio or Windows Local OS IIS. But when I deployed it to IIS 7.5 on Windows Server 2008 R2, the client methods wouldn't get invoked consistently. That was all because my application pool in deployment IIS server, had 10 working processors (i.e. Web Garden). This post helped me realize this and when I set the working processors to 1, It did the trick. Apparently this is by design.
From #AlexanderKöplinger:
This is by design. The two worker processes don't share state and clients will be distributed between them on a round-robin basis, which means 50% will connect to process A and 50% to process B. As the underlying SignalR message bus is in-memory by default, process A doesn't see messages from process B.
I'll set the working processor to 1 for now, but I'll try to find a way to make Web Garden work with SignalR.
Update:
Setting working processors to 1 is not good in regards of scaling. The SignalR team did provide us a way to make Web Garden work with SignalR and it's explained here. You have 3 methods to choose from and I decided to use the SQL server approach. The setup went smooth and easy and now SignalR is using SQL server as a backplane to share messages between different working processors.
At first sight, within your done() you are calling a Test method from the server which doesn’t exist or at least is missing. Removing this line could make it work.
We deployed to a local development server and SOME users (not all) experience a signalr problem where the serverSentEvents won't connect and it falls back to long polling... normally that would be fine but it takes 5 seconds to fall back and the user experience is horrible.
The request gets a status of "canceled" in chrome's developer tools network tab and we ultimately end up connecting using signalr's longPolling. Here's the logging from signalr:
[16:09:28 GMT-0500 (Eastern Standard Time)] SignalR: Client subscribed to hub 'chat'. jquery.signalR-2.0.0.js:75
[16:09:28 GMT-0500 (Eastern Standard Time)] SignalR: Negotiating with '/signalr/negotiate?connectionData=%5B%7B%22name%22%3A%22chat%22%7D%5D&clientProtocol=1.3'. jquery.signalR-2.0.0.js:75
[16:09:28 GMT-0500 (Eastern Standard Time)] SignalR: Attempting to connect to SSE endpoint 'http://mysubdomain.mydomain.com/signalr/connect?transport=serverSentEvents&con…bYUr2xEEBuw%3D%3D&connectionData=%5B%7B%22name%22%3A%22chat%22%7D%5D&tid=6'. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: serverSentEvents timed out when trying to connect. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: EventSource calling close(). jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: This browser supports SSE, skipping Forever Frame. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: Opening long polling request to 'http://mysubdomain.mydomain.com/signalr/connect?transport=longPolling&connecti…bYUr2xEEBuw%3D%3D&connectionData=%5B%7B%22name%22%3A%22chat%22%7D%5D&tid=2'. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: Long poll complete. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: LongPolling connected.
Once the client is finally connected via long polling, the site works fine but I still need to figure out why serverSentEvents is not working.
I can just disable serverSentEvents to get around this but it works for some people and not others so I'm wondering if there's some way to find out why it's failing for some people and not others.
Any advice on how to diagnose this?
It is taking 5 seconds to fallback from the Server-Sent Events transport because that is SignalR's default TransportConnectTimeout. This TimeSpan can be shortened via GlobalHost.Configuration.TransportConnectTimeout at app start.
There are many reasons SSE might fail. For example, there might be a router or firewall between your SignalR server and client that is coalescing or closing the chunked HTTP response that the Server-Sent Events transport relies on. It is difficult to know for sure what the exact cause of the SSE problem is when all I know is that the connection timed out.
I have a JSONP WCF service,using back end as MySql.It is working properly when i run it locally with visual studio.
Now we have hosted it in Windows Server 2003.
Now there is very strange problem occurring..
When I do a request with fiddler which does not require much processing internally, it gives me result 200 OK with desired output as response, But when I do a request which requires some internal data processing, it gives me 504 error(gateway time out error).
I also looked at C:\WINDOWS\system32\LogFiles to see if it logs any error but it shows ok result in fiddler request which is as follows:
Fields: date time s-sitename s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status
2010-04-07 10:08:06 W3SVC490896353 s-ip GET /InitialState.svc/GetInitialState reference=1&pageId=18 8080 - c-ip Fiddler 200 0 64
Can anyone please help me to resolve the problem ??
Or any ideas i can try to find out why it is happening ??
Any help will be appreciated...
It looks like a timeout on the client side, or on something between the server and the client.
Things to check:
Are you using a proxy server? Is there a timeout set on it?
How are you making the call from the client? What is the timeout setting on the client side?