I am not looking for these so-called "debugging" solutions which rely on println. I mean to attach a real debugger to a running Hadoop instance, and debugging it from a different machine.
Is this possible? How? jdb?
A nicely given at LINK
To debug task tracker, do following steps.
Edit conf/hadoop-env.sh to have following
export HADOOP_TASKTRACKER_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,address=5000,server=y,suspend=n"
Start Hadoop (bin/start-dfs.sh and bin/start-mapred.sh)
It will block waiting for debug connection
Connect to the server using Eclipse "Remote Java Application" in the Debug configurations and add the break points
Run a map reduce Job
I've never done it that way as I'd rather my "real" jobs run unhindered by debug-overhead (which can, under circumstances, change the environment conditions anyway): I debug "locally" against a pseudo-instance (normal debugging in eclipse is absolutely no problem), copying specific files from the live environment once I've isolated (by using e.g. counters) where the problem lies.
Related
I'm still rather new to the world of API programming in Solidworks PDM, and i have run into a cumbersome problem i was hoping to get some insight in: For many normal API's in PDM, it is simply enough to add the .DLL file in PDM-Administration as 'Debug', and from thereon out, whenever the solution in VisualStudio is being rebuild, the PDM-Administration will automatically grab the same DLL-file, the next time it is being called from PDM. This is great for Debugging, no problem here.
But, as soon as the API has to trigger a task (to be executed on a client PC), it can only be added to PDM as a normal task (no debug mode), then added to the 'Task Host Configuration' on the client, and then configured as a 'New Task' in PDM-Administration.
This all works fine; BUT, it takes quite some time to change anything, since the only way i can get changes to take effect, is first to rebuild the Solution in VisualStudio, then manually overwrite the DLL-file in PDM-Administration, and finally reboot the client-PC (to force-update which version of the add-in it sees).
I have tried; logging out/in-again(in PDM), restarting the explorer, and clearing the local PDM-Cache... nothing has happened here
Can any of you give me some advice on how you debug PDM API's?
or at least force-reload a addin on the clients.
Specifically suggestions to task-add'ins will be much appreciated. Thank You.
Unfortunately there isn't a clean way to debug task addins.
It is possible to attach your debugger to the PDM process itself but its not trivial. Here's the gist of it as explained by Lee Young,
It depends on what portion of the task you're attempting to debug. If
you're looking to debug the task setup in the Administration Tool, all
you need to do is attach to the conisioadmin.exe process.
To debug an executing task, it gets a little trickier. Load up your
add-in as usual and select your machine to be the only machine that
will execute the task. (In the task setup.) Close the administration
tool. You'll need to create a symlink from the file in the plugins
directory to your debug dll. I personally use DirLinker. The plugins
directory is located at AppData\Local\SolidWorks\SolidWorks Enterprise
PDM\Plugins\VaultName.
In your sourcecode, place a messagebox.show in the OnCmd method and
place a breakpoint at that line. Once the task loads up, the task will
wait for the messagebox to be closed. When the messagebox is shown,
you can attach to TaskExecutor.exe and then you'll be able to debug.
If you're not hitting breakpoints, make sure you have the correct .NET
framework version selected when debugging.
If you're still not hitting breakpoints, EPDM probably loaded another
instance of your dll into the plugins directory.
For simple task addins, my approach is to debug via the method you described (reload it manually every time). Proper logging will help a lot here (Print ex.StackTrace on every exception).
For more complex tasks, you can create a separate 'debug' project that has some hardcoded (or dynamic) inputs and calls your code. This will get you close before testing in the PDM environment. A PDM task is basically a COM process on the client machine so that's pretty simple to mimic, aside from the actual PDM Task environment, which is full of bugs.
Hope this helps.
I am currently running Simulations in Veins and/or Artery.
Is there an easy way (thats perhaps I just didn't find because I'm blind/stupid) to dump the Output created in the Console into a file, apart from running it slower than express mode and then using copy/paste?
Can I create these data while still running in express-mode?
The short answer: if by 'console output' you mean the event log, then yes you can, but no you shouldn't, for exactly the reason you mention: express mode disables this output.
The recommended way to collect data from your simulation is by recording it using "statistics", see also this page of the OMNeT++ tutorial.
You can log this information using the record-eventlog=true option in your omnetpp.ini (as described in more detail in the manual), but this produces huge files for veins and artery. This is because the event log is used more as a logging system. The best way to think of it is as debug output and development support: to quickly figure out why something isn't working correctly. I tried to (ab)use this feature for logging data -- please, save yourself the immense pains and use the statistics module.
Yes. Easiest way, From top bar, go to: Run > Run Configuration > Common tab > scroll down to output and select the name and the location of the output file.
Downside, each time you want to run a different application, it over writes the previous one that was created, so don't forget to back it up before you run a different simulation.
Good luck.
I have web config transformations set up that work fine when I publish to something like Azure. But selecting between Release and Debug locally seems worthless if the web.config transformations don't actually get applied when running locally.
Is there any way to get these transformations to apply when I click "run"? If not, what's the point of having that dropdown? I'm genuinely curious, not asking rhetorically.
The idea for web.config transforms is that you have some settings that change between environments. For example, you might have a local development connection string, and you'll always use that when running/debugging locally. When you publish to your production server, though, you want to use your production DB. Debug vs. Release configurations at build time just change some settings in how your project is built (most commonly, how debug symbols are generated or what compiler optimizations are enabled), whereas web.config transforms are changing the content of what gets deployed (in web.config).
If you do want to apply the web.config transforms locally on F5, there are extensions that allow you to do so. Slow Cheetah is one such. However, in many cases, you probably don't need this as your web.config will stay mostly constant whenever you run locally.
Almost all IDEs have release and debug modes, in the debug mode, the code is compiled using debug flags and not so much optimization, i.e., some relation between the built program and the source code is kept, in this way you can run your code using a debugger, it is a tool that allows you to track and control the flow of execution of your application, for example the value stored in some variable in some situation in your code, this in order to expose semantic problems that your application may have, i.e., when your code is not actually doing what you expect it to be doing (most of the people does this using print statements everywhere at least once).
The release mode is aimed to produce an optimized version of your application, without debugging/profiling flags.
Notice that this have nothing to do with debug mode of web applications, where we set automated views to show more information when a run time error occurs, it just have to do with optimization or debugging of the actual program running underneath. So setting debug or release mode may not change whether a web application shows tracebacks or not, but it certainly changes the performance of the application running locally in your server.
Regards.
I have set of JVM configured, WAS components (Queues, SIB, etc) created in one environment (WAS 8.0 ) and is all working fine. I need to replicate the same in another set of new servers (and another one potentially). How do I replicate all the steps without typing the information again?
Ideally, you'd make the original changes via scripting and re-run them. An alternative is "properties based configuration" for export/import.
http://www.ibm.com/developerworks/websphere/techjournal/0904_chang/0904_chang.html
We develop software, which constantly needs to be debugged on both Linux and Windows. The way I would like to do this is to have an option in Eclipse (PyDev) saying "Debug this application on the remote Linux server". I then want the option to execute the code line-by-line.
Does such a feature exist in Eclipse? If it does not exist in Eclipse, what is the recommended approach to do such a thing? I have thought about installing Eclipse also on the Linux server, but then I have the extra work of configuring and maintaining several eclipse setups.
Have you read: http://pydev.org/manual_adv_remote_debugger.html ?
One thing you cannot escape from right now is having the sources for the debugger in the platform you want to run... (although you don't need eclipse itself there, at least you need the contents of org.python.pydev.debug/pysrc there, so, maybe you can create your script which will copy those from a 'central' location you keep updated, or if you have a shared folder, just add that network folder to your pythonpath).