i'm using WebSockets to send data from my node.js server to my clients. Since the data can be kind of large, the UI thread used to block, so no user interaction or video playing was possible during the data was received. That's when i stumbled over WebWorkers, and i also managed to get them work together with WebSockets.
app.js:
...
var worker = new Worker('worker.js');
worker.addEventListener('message', function(e) {
console.log('Worker said: ', e.data);
}, false);
worker.postMessage('init');
...
worker.js:
function initWebSocket() {
var connection = new WebSocket('ws://host:port', ['soap', 'xmpp']);
connection.onopen = function () {
connection.send('Ping'); // Send the message 'Ping' to the server
};
// Log errors
connection.onerror = function (error) {
console.log('WebSocket Error ' + error);
};
// Log messages from the server
connection.onmessage = function (e) {
console.log('Server: ' + e.data);
//self.postMessage('Worker received : ' + e.data);
};
};
self.addEventListener('message', function(e) {
switch (e.data) {
case 'init':
initWebSocket();
break;
default:
self.postMessage('Unknown command: ' + e.data);
};
}, false);
All i'm doing so far is receive the data. Of course, later on i intend to do more stuff with it. But my problem is: The UI thread is still blocking when large files arrive. Did i get something wrong here?
UPDATE:
Actually, i have to revise my previous comment. Obviously chrome had cached some of my files i was sending before, so i didn't realize the problem starts already with files way smaller than 300MB (currently, i'm testing a 50MB file). The ui blocks until the file has been completly received. What i'm currently doing is the following: I'm loading an index page with a video playing. Also, on the same page, i put a button which starts a worker. The worker does send an xhr request to the server and gets a 50MB file. So i just dismissed WebSockets for the sake of it. What's happening when i click the button: The video freezes until the complete data has been received. When i do the same and let the worker just calculate numbers in a for-loop, the video keeps playing. So it seems to have something to work with using the network, but not specifically WebSockets. Is it possible that WebWorkers just can't work with network stuff?
Related
There is a simple web server that accepts data. Sample code below.
The idea is to track in real time how much data has entered the server and immediately inform the client about this. If you send a small amount of data, then everything works well, but if you send more than X data in size, then the on.data event on the server is triggered with a huge delay. I can see that data is transfering for 5 seconds already but on.data event is not trigerred.
on.data event seems to be triggered only when data is uploaded completely to the server, so that's why it works fine with small data (~2..20Mb), but with big data (50..200Mb) it doesnt work well.
Or maybe it is due to some kind of buffering..?
Do you have any suggestions why on.data triggered with delay and how to fix it?
const app = express();
const port = 3000;
// PUBLIC API
// upload file
app.post('/upload', function (request, response) {
request.on('data', chunk => {
// message appears with delay
console.log('upload on data', chunk.length);
// send message to the client about chunk.length
});
response.send({
message: `Got a POST request ${request.headers['content-length']}`
});
});
app.listen(port, () => {
console.log(`Example app listening at http://localhost:${port}`);
});
TLDR:
The delay that you are experiencing probably is the Queueing from Resource scheduling from the browser.
The Test
I did some tests with express, and then I found that it uses http to handle requests/response, so I used a raw http server listener to test this scenario, which has the same situation.
Backend code
This code, based on sample of Node transaction samples, will create a http server and give log of time on 3 situations:
When a request was received
When the first data event fires
When the end event fires
const http = require('http');
var firstByte = null;
var server = http.createServer((request, response) => {
const { headers, method, url } = request;
let body = [];
request.on('error', (err) => {
}).on('data', (chunk) => {
if (!firstByte) {
firstByte = Date.now();
console.log('received first byte at: ' + Date.now());
}
}).on('end', () => {
console.log('end receive data at: ' + Date.now());
// body = Buffer.concat(body).toString();
// At this point, we have the headers, method, url and body, and can now
// do whatever we need to in order to respond to this request.
if (url === '/') {
response.statusCode = 200;
response.setHeader('Content-Type', 'text/html');
response.write('<h1>Hello World</h1>');
}
firstByte = null;
response.end();
});
console.log('received a request at: ' + Date.now());
});
server.listen(8083);
Frontend code (snnipet from devtools)
This code will fire a upload to /upload which some array data, I filled the array before with random bytes, but then I removed and see that it did not have any affect on my timing log, so yes.. the upload content for now is just an array of 0's.
console.log('building data');
var view = new Uint32Array(new Array(5 * 1024 * 1024));
console.log('start sending at: ' + Date.now());
fetch("/upload", {
body: view,
method: "post"
}).then(async response => {
const text = await response.text();
console.log('got response: ' + text);
});
Now running the backend code and then running the frontend code I get some log.
Log capture (screenshots)
The Backend log and frontend log:
The time differences between backend and frontend:
Results
looking at the screenshoots and I get two differences between the logs:
The first, and most important, is the difference between frontend fetch start and backend request recevied, I got 1613ms which is "close" (1430ms) to Resource Scheduling in network timing tab, I think there are more things happening between the frontend fetch call and the node backend event, so I can't direct compare the times:
log.backendReceivedRequest - log.frontEndStart
1613
The second is the difference between receving data on backend, which I got
578ms, close to Request sent (585ms) in network timing tab:
log.backendReceivedAllData - log.backendReceivedFirstData
578
I also changed the frontend code to send different sizes of data and the network timing tab still matches the log
The thing that remains unknown for me is... Why does Google Chrome is queueing my fetch since I'm not running any more requests and not using the bandwidth of the server/host? I readed the conditions for Queueing but not found the reason, maybe is allocating the resources on disk, but not sure: https://developer.chrome.com/docs/devtools/network/reference/#timing-explanation
References:
https://nodejs.org/es/docs/guides/anatomy-of-an-http-transaction/
https://developer.chrome.com/docs/devtools/network/reference/#timing-explanation
I found a problem. It was in nginx config. Nginx was setup like a reverse proxy. By default proxy request buffering is enabled, so nginx grabs first whole request body and only then forwards it to nodejs, so that's why I saw delay.
https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_request_buffering
I have a logging API in which is executed before a link. The link will be redirecting the user to other place and I'm executing fetch before the user is redirected. So the script is like this now:
loggingAPI({
timestamp: moment()
})
window.location = "http://.......com"
The logging api is just a normal fetch wrapper.
However, the server doesn't receive the API request right now. I think it's because of it doesn't even get the chance to send the request to the api.
So can I wait for the request to be sent but not waiting for the response?
Using sendBeacon it's very simple
without seeing the code for you function loggingAPI the following is a best guess
Note: sendBeacon uses a POST request, so the server side may need to be modified to accept such a request - though, seeing as your loggingAPI is sending data, I imagine it is already using POST - so this may be a non-issue
somewhere in your code, set up an unload event for windows
window.addEventListener("unload", () => {
sendBeacon("same url as loggingAPI", JSON.stringify({timestamp: moment()}));
}, false);
Then, when you
window.location = "http://.......com"
the loggingAPI function gets called for you
edit: sorry, I didn't flesh out the code fully, I missed a few steps!!
You can send the request in a service worker.
https://developers.google.com/web/fundamentals/primers/service-workers/
Here's some fetch specific information:
https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent
You would register the service worker, and then send a message to it before redirecting.
The upside to the initial complexity is that once you start using service workers, they open up a whole new world of programming; You will end up using them for much more then queuing up messages to send.
Step 1 Register a service worker
index.html
if ('serviceWorker' in navigator) {
window.addEventListener('load', function() {
navigator.serviceWorker.register('service-worker.js').then(function(registration) {
// Registration was successful
console.log('ServiceWorker registration successful with scope: ', registration.scope);
}, function(err) {
// registration failed :(
console.log('ServiceWorker registration failed: ', err);
});
});
}
Step 2 Create the service worker script
service-worker.js
self.addEventListener('install', function(e) {
return Promise.resolve(null)
});
Step 3 Create a listener in server worker script
service-worker.js
self.addEventListener('message', function (event) {
console.log('message', event.data)
// call fetch here, catching and responding to what you stashed in the message
});
Step 4 Send the message before you redirect
index.html
Just a demo to simulate your client.
setTimeout(() => {
navigator.serviceWorker.controller.postMessage({message: 'A LOG MESSAGE'});
}, 2000)
After you put all pieces in place, MAKE SURE YOU CLOSE ALL TABS AND REOPEN, or have chrome dev tools set up to deal with refreshing the worker.
An old question, but if you're using fetch you can use the keepalive flag.
The keepalive option can be used to allow the request to outlive the page. Fetch with the keepalive flag is a replacement for the Navigator.sendBeacon() API.
https://developer.mozilla.org/en-US/docs/Web/API/fetch#keepalive
I am new to webworker but I managed to send xmlhttprequest to my rest api and I got json back. But I want send this request again and again (in a loop), until the page is active.
I actually want to show values in real time. I want to make a simple web application in which when data is inserted in database my webworker should show that data without refreshing the page.
Is there any better way to do so. Kindly help me in it.
sorry for bad English.
You can use EventSource to get stream from server until .close() is called at Worker, or message is passed to Worker signalling Worker to call .close().
const es = new EventSource("/path/to/server");
es.addEventListener("open", function(event) {
console.log("event source open")
});
es.addEventListener("message", function(event) {
// do stuff with `event.data`
console.log(event.data);
});
es.addEventListener("error", function(event) {
console.log("event source error", event)
});
button.addEventListener("click", function() {
es.close();
});
Looking at the example given at the nodejs domain doc page: http://nodejs.org/api/domain.html, the recommended way to restart a worker using cluster is to call first disconnect in the worker part, and listen to the disconnect event in the master part. However, if you just copy/paste the example given, you will notice that the disconnect() call does not shutdown the current worker:
What happens here is:
try {
var killtimer = setTimeout(function() {
process.exit(1);
}, 30000);
killtimer.unref();
server.close();
cluster.worker.disconnect();
res.statusCode = 500;
res.setHeader('content-type', 'text/plain');
res.end('Oops, there was a problem!\n');
} catch (er2) {
console.error('Error sending 500!', er2.stack);
}
I do a get request at /error
A timer is started: in 30s the process will be killed if not already
The http server is shut down
The worker is disconnected (but still alive)
The 500 page is displayed
I do a second get request at error (before 30s)
New timer started
Server is already closed => throw an error
The error is catched in the "catch" block and no result is sent back to the client, so on the client side, the page is waiting without any message.
In my opinion, it would be better to just kill the worker, and listen to the 'exit' event on the master part to fork again. This way, the 500 error is always sent during an error:
try {
var killtimer = setTimeout(function() {
process.exit(1);
}, 30000);
killtimer.unref();
server.close();
res.statusCode = 500;
res.setHeader('content-type', 'text/plain');
res.end('Oops, there was a problem!\n');
cluster.worker.kill();
} catch (er2) {
console.error('Error sending 500!', er2);
}
I'm not sure about the down side effects using kill instead of disconnect, but it seems disconnect is waiting the server to close, however it seems this is not working (at least not like it should)
I just would like some feedbacks about this. There could be a good reason this example is written this way that I've missed.
Thanks
EDIT:
I've just checked with curl, and it works well.
However I was previously testing with Chrome, and it seems that after sending back the 500 response, chrome does a second request BEFORE the server actually ends to close.
In this case, the server is closing and not closed (which means the worker is also disconnecting without being disconnected), causing the second request to be handled by the same worker as before so:
It prevents the server to finish to close
The second server.close(); line being evaluated, it triggers an exception because the server is not closed.
All following requests will trigger the same exception until the killtimer callback is called.
I figured it out, actually when the server is closing and receives a request at the same time, it stops its closing process.
So he still accepts connection, but cannot be closed anymore.
Even without cluster, this simple example illustrates this:
var PORT = 8080;
var domain = require('domain');
var server = require('http').createServer(function(req, res) {
var d = domain.create();
d.on('error', function(er) {
try {
var killtimer = setTimeout(function() {
process.exit(1);
}, 30000);
killtimer.unref();
console.log('Trying to close the server');
server.close(function() {
console.log('server is closed!');
});
console.log('The server should not now accepts new requests, it should be in "closing state"');
res.statusCode = 500;
res.setHeader('content-type', 'text/plain');
res.end('Oops, there was a problem!\n');
} catch (er2) {
console.error('Error sending 500!', er2);
}
});
d.add(req);
d.add(res);
d.run(function() {
console.log('New request at: %s', req.url);
// error
setTimeout(function() {
flerb.bark();
});
});
});
server.listen(PORT);
Just run:
curl http://127.0.0.1:8080/ http://127.0.0.1:8080/
Output:
New request at: /
Trying to close the server
The server should not now accepts new requests, it should be in "closing state"
New request at: /
Trying to close the server
Error sending 500! [Error: Not running]
Now single request:
curl http://127.0.0.1:8080/
Output:
New request at: /
Trying to close the server
The server should not now accepts new requests, it should be in "closing state"
server is closed!
So with chrome doing 1 more request for the favicon for example, the server is not able to shutdown.
For now I'll keep using worker.kill() which makes the worker not to wait for the server to stops.
I ran into the same problem around 6 months ago, sadly don't have any code to demonstrate as it was from my previous job. I solved it by explicitly sending a message to the worker and calling disconnect at the same time. Disconnect prevents the worker from taking on new work and in my case as i was tracking all work that the worker was doing (it was for an upload service that had long running uploads) i was able to wait until all of them are finished and then exit with 0.
So I'm implementing an application that requires messages to be sent to the browser in real time. Currently this is working fine. When I receive a message I an Untyped Actor similar to the clock example.
What my issue is though is I would like to be able to reconnect the web page when the comet socket gets disconnected. Currently in chrome with comet sockets the loading icon continuously spins. Is there a way I can catch a disconnect message for the iframe/comet socket? Or is there something that I can poll in javascript/jquery? So i can then just reload the page?
If you want to reconnect "the web page" (in other words, make your browser send another request to server, with window.location.reload() or some other method), standard play.libs.Comet.onDisconnected handler is of no use to you - its domain is a server-side, not a client-side.
To make your client-side manage possible blackouts by itself, you may need to implement 'heartbeat' scheme. The client application will ping your server when too much time has been passed since the previous message. One possible way to do this:
var CometProcessor = {
processMessage: function(message) {
console.log(message);
},
handleHeartbeatTimeout: function() {
alert('Heartbeat process timeout');
},
handleHeartbeatError: function() {
alert('Heartbeat process error');
},
timeoutPeriod: 10000, // in milliseconds
timeoutId: 0, // will contain an ID of the current 'checking' timeout
checkHandler: null, // will contain a link to XHR object
checkBeat: function() {
// storing the reference to created XHR object:
this.checkHandler = $.ajax({
url: your_server_url,
// set it to the URL of ping script, that will respond instantly
timeout: 1000,
// this is configurable, but obviously it makes little sense setting this param
// higher than `timeoutPeriod`
success: $.proxy(function() {
// so this particular heartbeat request check went through ok,
// but the next may not be so lucky: we need to schedule another check
this.timeoutId = window.setTimeout(
$.proxy(this.checkBeat, this), this.timeoutPeriod);
}, this),
error: $.proxy(function(x, t) {
if (t === 'timeout') {
this.handleHeartbeatTimeout();
}
else {
this.handleHeartbeatError();
}
}, this)
});
},
message: function(message) {
// when we receive a message, link is obviously functioning,
// so we need to stop all the checking procedures
if (this.checkHandler) {
this.checkHandler.abort();
window.clearTimeout(this.timeoutId);
this.checkHandler = null;
}
processMessage(message); // this is where the actual processing takes place
// when we done with processing, we need to setup the heartbeat again:
this.timeoutId = window.setTimeout(
$.proxy(this.checkBeat, this), this.timeoutPeriod);
}
};
Leveraging this object at server-side is quite easy: you just have to replace the line similar to the one in this example...
Ok.stream(events &> Comet(callback = "parent.cometMessage"))
... with this:
Ok.stream(events &> Comet(callback = "parent.CometProcessor.message"))