[Pharo-dev] Debugging in Production Servers

Torsten Bergmann astares at gmx.de
Thu Apr 24 05:26:32 EDT 2014


>The good developers / expert users will not do what you state. The eclipse debug, inspector, watches >are very much part of a normal dev cycle in our place with around 100 devs.

This is not a problem of being expert or not. In languages like C/C++ you often need 
to deploy additional debug infos with the runtime (debug symbols in COFF, ...) to get
anything useful - which usually is not done by default and needs additional effort 
if you want to debug in production.

Situation in Java is better from the tooling side because there are no different
CPU architectures/instruction sets to consider - just one bytecode set and one JVM. 
There are nice tools to monitor or debug - but still you have to run the JVM with 
debug option and debugging from the external side to get the right debugging experience
with stepping through the code.

So if you want to debug a web-app in Java the same way you debug at development time 
you would have to restart your JBoss, Websphere, ... and connect to a specific debug port. 
That is usually not done in a productive Java app because of a production downtime,
limited developer access to it, ...
And yes - there is JMX with MBeans, but this is more for monitoring than real debugging.


Comparing inspectors of Eclipse with the inspectors of Smalltalk is comparing apples
with oranges. For sure Eclipse has catched up with the IDE and is now also 
providing inspectors in the UI, also allows evaluating limited expression and 
good watches. 

In Smalltalk you can implement you own inspectors/install them at runtime/change 
similar to anything other. You can even load new tools and later remove them while running.
As we know Smalltalk is different in many regards.

Typical Debugging in other languages is often dealing with the already deceased.
Developers work with logging info from production or at a crashed heap dump, etc.
Errors are then often reproduced back in the IDE/dev environment. 

Unfortunately this often means additional costs and more time before a fix is ready
- but the World seems to be satisfied with this already

In Smalltalk you can easily catch specific cases while running. You can easily
add code at runtime to check issues (if developer tools are not stripped):

  shopItem id = 1234567 ifTrue: [ shopItem inspect ]

and even save a copy of the image at a specific point in time/situation for offline 
inspection. This is not comparable to a dump because the time to debug in ST tends to zero. 
While in Java you have to resetup the environment/IDE with the code version, etc.

You can even manipulate and fix data in production easily with Smalltalk:

  shopItem id = 1234567 ifTrue: [ shopItem price: 12.3s2 ]

And ... you can also shoot yourself in the foot if not done carefully ;)

Debugging in Smalltalk is different: you do not debug from the outside - you
do not have to restart the program and navigate to the point where it happened. 
If the developer tools are included you can just switch and use them. You also
do not have to recompile the whole thing when you found the problem. If there
is an easy workaround you can directly apply it to your program and later fix
it in the development stream.

So Smalltalk - as a changeable dynamic object system - is here more comparable to a database.
You do not have to stop while it is running in production and you can change and
inspect or even fix the program at will. With all the up's and downs of this approach.

I doubt that this could/should be marketed as a killer feature. We should keep
it as our own little secret.

But it is not only a question of technical feasability: often "production environment" 
is seen as "holy" and "untouchable"  for other reasons like security. So nobody
is missing something when the developers do not debug/work directly in production.

Bye
T.




 
 





More information about the Pharo-dev mailing list