I have multiple process producing traces in separate files, so I want to sync them to display on a single timeline. Let's say I have 2 files.
agent_service_trace.json:
{"traceEvents":[
{"cat":"AgentService","pid":6876,"tid":6868,"ts":0,"ph":"X","name":"wWinMain","args":{},"dur":448701329},
{"cat":"","pid":6876,"tid":6868,"ts":3,"ph":"M","name":"process_name","args":{"name":"AgentService"}},
{"cat":"","pid":6876,"tid":6868,"ts":20,"ph":"M","name":"thread_name","args":{"name":"Main thread"}}
]}
agent_host_trace.json:
{"traceEvents":[
{"cat":"AgentHost","pid":6564,"tid":6440,"ts":0,"ph":"X","name":"wWinMain","args":{},"dur":448701329},
{"cat":"","pid":6564,"tid":6440,"ts":5,"ph":"M","name":"process_name","args":{"name":"AgentHost"}},
{"cat":"","pid":6564,"tid":6440,"ts":10,"ph":"M","name":"thread_name","args":{"name":"Main host"}}
]}
They are started with slight difference in time, from few seconds up to few minutes. When I'm combining them one by one, since ts arg is time from the beginning of process tracing, they looks like were started at the same point in time.
From the tracing documentation and clock sync addition especially, I'v found that Clock Sync event was created to handle multiple trace logs produced by different tracing agents and synchronize their clock domains. But as I know chrome://tracing doesn't support multiple files at time. The thing I'v tried so far, were adding clock_sync to events:
{"traceEvents":[
{"ts":0,"ph":"c","name":"clock_sync","args":{"sync_id":"guid0","sync_ts":0}},
{"cat":"AgentService","pid":6876,"tid":6868,"ts":0,"ph":"X","name":"wWinMain","args":{},"dur":448701329},
{"cat":"","pid":6876,"tid":6868,"ts":3,"ph":"M","name":"process_name","args":{"name":"AgentService"}},
{"cat":"","pid":6876,"tid":6868,"ts":20,"ph":"M","name":"thread_name","args":{"name":"Main thread"}},
{"ts":0,"ph":"c","name":"clock_sync","args":{"sync_id":"guid1","sync_ts":30000}},
{"cat":"AgentHost","pid":6564,"tid":6440,"ts":0,"ph":"X","name":"wWinMain","args":{},"dur":448701329},
{"cat":"","pid":6564,"tid":6440,"ts":5,"ph":"M","name":"process_name","args":{"name":"AgentHost"}},
{"cat":"","pid":6564,"tid":6440,"ts":10,"ph":"M","name":"thread_name","args":{"name":"Main host"}}
]}
I really don't know how this supposed to work, I'v tried to add sync_id as arg to events, also tried add pid as arg to clock_sync event. All of mine manipulations had no effect. I though there must be a link inbetween events and clock_sync's sync_id, but unable to find any info on this. I would appreciate any help.
Related
In using realbrowserlocusts class it appears that I'm limited in any exception handling.
The only reference that partially works is: self.client.wait.until(EC.visibility_of_element_located ....
In a failed condition where the element is not found the script simply starts over again. With the script I'm working with I need to maintain a solid session state; I need to throw and exception(report an error), log the user out and then let the script start over again. I've been testing out the behavior with the locust.py script that Nick B. created with several approaches to "try, except" and they work running without realbrowserlocusts (selenium only) but with it the execution just stops.
Any examples would be greatly appreciated.
In its current format I've been able to run 3x the amount of a browser-based load per/agent/slave than our commercial tool. My goal is to replace it with a locust/selenium approach.
locust-plugins's WebdriverUser has a little bit better exception handling I think. A failure to find an element will log a failed request and if you use RescheduleTaskOnFail (as in the the example) it will restart the task when that happens.
https://github.com/SvenskaSpel/locust-plugins/blob/master/examples/webdriver_ex.py
We are running a Chrome from a linux service and sometimes the instance of chrome freeze (and all the computer too) unexpectedly with the following error :
May 27 21:57:51 Q190N-prototype google-chrome[24703]: [24703:24703:0527/215751.950576:INFO:CONSOLE(342)] "nextVideo()", source: http://192.168.22.16/animatic/static/js/player/index.js?ver=1558013787 (342)
May 27 21:57:51 Q190N-prototype google-chrome[24703]: [24703:24703:0527/215751.952062:INFO:CONSOLE(342)] "nextVideo()", source: http://192.168.22.16/animatic/static/js/player/index.js?ver=1558013787 (342)
May 27 21:58:03 Q190N-prototype google-chrome[24703]: [24703:24703:0527/215803.050265:INFO:CONSOLE(342)] "nextVideo()", source: http://192.168.22.16/animatic/static/js/player/index.js?ver=1558013787 (342)
May 27 21:58:03 Q190N-prototype google-chrome[24703]: [24703:24703:0527/215803.051856:INFO:CONSOLE(342)] "nextVideo()", source: http://192.168.22.16/animatic/static/js/player/index.js?ver=1558013787 (342)
^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#
^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#
^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#
^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#May 28 10:33:49 Q190N
-prototype lvm[213]: 2 logical volume(s) in volume group "debian-vg" monitored
May 28 10:33:49 Q190N-prototype keyboard-setup.sh[211]: Impossible d'ouvrir le fichier /tmp/tmpkbd.k7WSzt
Any idea in order to solve this problem is welcome...
You probably have a problem on index.js or another imported script.
There are a list of possibilities, but most times freeze is caused by while(true) or long loops.
If this is the problem, try:
You can break the calculation up into pieces and do a piece at a time on a
setTimeout(). On each setTimeout() call, the browser will be free to serve other
events and will keep the page alive and responive. When you finish the last piece of the calculation, you can then carry out the result.
You can run the calculation in the background using a webworker in modern browsers. When the calcuation is done in the webworker, it sends a message back to the main thread and you can then update the DOM with the result.
This answer might help: https://stackoverflow.com/a/49961782/11578778
I hope this helps!
Brhaka
This seems like a buffer overflow to me, Q190N-prototype keyboard-setup.sh is the linux keyboard map and stores the map file in /tmp.
/tmp/tmpkbd.k7WSz seems like the map file for keyboard binding.
^#^#^#^#^#^#^#^#^#^#^#^# is definitely garbage from memory. Now the question is what are how is your player jumping to this address. Is it waiting for some keyboard input at some point of time while playing media. May be at the end when to play next or something.
Its either a permission or file not found issue
try it with sudo once and see if you can reproduce the error
I have written a script to update my db table after reading data from db tables and solr. I am using asyn.waterfall module. The problem is that the script is not getting exited after successful completion of all operations. I have used db connection pool also thinking that may be creating the script to wait infinitly.
I want to put this script in crontab and if it will not exit properly it would be creating a hell lot of instances unnecessarily.
I just went through this issue.
The problem with just using process.exit() is that the program I am working on was creating handles, but never destroying them.
It was processing a directory and putting data into orientdb.
so some of the things that I have come to learn is that database connections need to be closed before getting rid of the reference. And that process.exit() does not solve all cases.
When my project processed 2,000 files. It would get down to about 500 left, and the extra handles would have filled up the available working memory. Which means it would not be able to continue. Therefore never reaching the process.exit at the end.
On the other hand, if you close the items that are requesting the app to stay open, you can solve the problem at its source.
The two "Undocumented Functions" that I was able to use, were
process._getActiveHandles();
process._getActiveRequests();
I am not sure what other functions will help with debugging these types of issues, but these ones were amazing.
They return an array, and you can determine a lot about what is going on in your process by using these methods.
You have to tell it when you're done, by calling
process.exit();
More specifically, you'll want to call this in the callback from async.waterfall() (the second argument to that function). At that point, all your asynchronous code has executed, and your script should be ready to exit.
EDIT: As pointed out by #Aaron below, this likely has to do with something like a database connection being active, and not allowing the node process to end.
You can use the node module why-is-node-running:
Run npm install -D why-is-node-running
Add import * as log from 'why-is-node-running'; in your code
When you expect your program to exit, add a log statement:
afterAll(async () => {
await app.close();
log();
})
This will print a list of open handles with a stacktrace to find out where they originated:
There are 5 handle(s) keeping the process running
# Timeout
/home/maf/dev/node_modules/why-is-node-running/example.js:6 - setInterval(function () {}, 1000)
/home/maf/dev/node_modules/why-is-node-running/example.js:10 - createServer()
# TCPSERVERWRAP
/home/maf/dev/node_modules/why-is-node-running/example.js:7 - server.listen(0)
/home/maf/dev/node_modules/why-is-node-running/example.js:10 - createServer()
We can quit the execution by using:
connection.destroy();
If you use Visual Studio code, you can attach to an already running Node script directly from it.
First, run the Debug: Attached to Node Process command:
When you invoke the command, VS Code will prompt you which Node.js process to attach to:
Your terminal should display this message:
Debugger listening on ws://127.0.0.1:9229/<...>
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Then, inside your debug console, you can use the code from The Lazy Coder’s answer:
process._getActiveHandles();
process._getActiveRequests();
I had a non-OSGi application. To convert it to OSGi, I first bundled it up and gave it a simple BundleActivator. The activator's start() started up a thread of what used to be the main() of my app (and is now a Runnable), and remembered that thread. The activator's stop() interrupted that thread, and waited for it to end (via join()), then returned. This all seemed to be working fine.
As a next step in the OSGiification process, I am now trying to use OSGi configuration management instead of the Properties-based configuration that the application used to use. So I am adding in a ManagedService in addition to the Activator.
But it's no longer clear to me how I am supposed to start and stop my application; examples that I've seen are only serving to confuse me. Specifically, here:
http://felix.apache.org/site/apache-felix-config-admin.html
They no longer seem to do any real starting of the application in BundleActivator.start(). Instead, they just register a ManagedService to receive configuration. So I'm guessing maybe I start up the app's main thread when I receive configuration, in the ManagedService? They don't show it - the ManagedService's updated() just has vague comments saying to "apply configuration from config admin" when it is passed a non-null Dictionary.
So then I look here:
http://blog.osgi.org/2010/06/how-to-use-config-admin.html
In there, it seems like maybe they're doing what I guessed. They seem to have moved the actual app from BundleActivator to ManagedService, and are dealing with starting it when updated() receives non-null configuration, stopping it first if it's already started.
But now what about when the BundleActivator's stop() gets called?
Back on the first example page that I mentioned above, they unregister the ManagedService. On the second example page, they don't show what they do.
So I'm guessing maybe unregistering the ManagedService will cause null configuration to be sent to ManagedService.updated(), at which point I can interrupte the app thread, wait for it to end, and then return?
I suspect that I'm thoroughly incorrect, but I don't know what the "real" way to do this is. Thanks in advance for any help.
BundleActivator (BA) and ManagedService (MS) are callbacks to your bundle. BundleActivator is for the active state of your bundle. BA.start is when you bundle is being started and BA.stop is when it is being stopped. MS is called to provide your bundle a configuration, if there is one, or notify you there is no configuration.
So in BA.start, you register your MS service and return. When MS is called (on some other thread), you will either receive your configuration or be told there is no configuration and you can act accordingly (start app, etc.)
Your MS can also be called at anytime to advice of the modification or deletion of your configuration and you should act accordingly (i.e. adjust your app behavior).
When you are called at BA.stop, you need to stop your app. You can unregister the MS or let the framework do it for you as part of normal bundle stop processing.
Thanks for your reply for my question: Is this a bug of Box API v2 when getting events
This is a new problem related to this. The problem is that I cannot reliably use the next_stream_position I got from previous calls to track events.
Given this scenario:
Given the following two GET HTTP queries:
1. GET https://api.box.com/2.0/events?stream_position=1336039062458
This one returns the JSON file which contains one file entry of myfile.pdf and the next stream position = 1336039062934
2. GET https://api.box.com/2.0/events?stream_position=1336039062934
This call uses the stream position I got from the first call. However, it returns the JSON contains the exactly same file entry of myfile.pdf with the first call.
I think if the first call gives a stream position, it should be used as a mark for that exact time (say: TIme A). If I use that stream position in subsequent queries, no events before "Time A" should be returned.
Is this a bug? Or did I use the API in the wrong way?
Many thanks.
Box’s /events endpoint is focused on delivering to you a highly reliable list of all the events relevant to your Box account. Events are registered against a time-sequenced list we call the stream_position. When you hit the /events API and pass in a stream_position we respond to you with the events that happened slightly before that stream position, up to the current stream_position, or the chunk_size, whichever is lesser. Due to timing lag and our preference to make sure you don’t miss some event, you may receive duplicate events when you call the /events API. You may also receive events that look like they are ‘before’ events that you’ve already received. Our philosophy is that it is better for you to know what has happened, than to be in the dark and miss something important.
Box events currently give you a window roughly 5 seconds into the past, so that you don't miss some event.
We have considered just delaying the events we send you by about 5 seconds and de-duplicating the events on our side, but at this point we've turned the dial more towards real-time. Let us know if you'd prefer a fully de-duped stream, that was slower.
For now, (in beta) if you write your client to check for duplicate events, and discard them, that will be best. We are about to add an event_id to the payload so you can de-duplicate on that. Until then, you'll have to look at a bunch of fields, depending on the event type... It's probably more challenging that it is worth.
In order to help you be able to figure out if an event is a duplicate, we have now added to each event an event_id that will be unique. It is our intention that the event_id will allow you to de-duplicate the responses you receive from subsequent GET /events calls.
You can see this reflected in the updated documentation here, including example payloads.