Debugging in Production Servers
Locked
12
12
 
Administrator
|
Smalltalk has the capability of allowing live debugging in production servers. How unique is this capability? What other systems allow that?
Is there a name for such capability? Can we coin one and market it? What are the pros and cons of having such a capability? All the best, Aik-Siong Koh |
|
|
One can easily do that with Java / Eclipse or for
VC++ / Visual Studio with attach to process. Probably I would reckon
these to be more "secure" as industry prefers rather than having live
debug capabilities built in to the code delivered or somehow "in-process". I am sure all others
as in python, ruby et als will have debug in prod capabilities if reqd. Javascript with Rhino also can easily allow live debug if the reqd jar is present.. The bigger purchase Smalltalk gives is in reflection that can be leveraged to produce fairly extensive logger reports which no other langauge currently does when fault occurs in production. I doubt in production the industry is as of now willing to let debug be acceptable specially in Banking domain. The smalltalk advantages are not translating into business gains per se given the comfort zone of security, safety production systems are wrapped in procedurally. On Thu, Apr 24, 2014 at 7:39 AM, askoh <[hidden email]> wrote: Smalltalk has the capability of allowing live debugging in production |
|
Administrator
|
Thanks for reply. Are there cases of Java/Eclipse running in Production? Similarly with VC++ / Visual Studio? They would be very very slow wouldn't they?
I am referring to real use case of live debugging in Production servers. I agree that this capability might not be attractive from point of view of security and safety. But there are insurance and financial companies that use Smalltalk. How do they view this capability? Do they forbid it totally? If they allow it, how do they prevent abuse? The pros is of course the easy of finding bugs and inspection of states during production. All the best, Aik-Siong Koh |
|
|
The capability exists, any dev team can take advantage if reqd of it, I am sure many may have in rare occassions. On the remote on the same LAN it will not be any different than debug is for eclipse / VisualStudio in dev. In Insurance, Banking in my experience, it will be the last resort, unless it is critical and there is no other alternative to it but with production data set. As I reiterated the reflection based data gathering that can enabled along with the superb exception handling capability it is something that is leveraged by smalltalk in production ( Unicycle reports in VA) and that is terrific for resolving bugs. Reflection based tools like in Groovy can bring any Java system close to Smalltalk offers also in production as I have done in my work place. On Thu, Apr 24, 2014 at 9:50 AM, askoh <[hidden email]> wrote: Thanks for reply. Are there cases of Java/Eclipse running in Production? |
Re: Debugging in Production Servers
|
|
In reply to this post by S Krish
I am sorry, but I disagree.
Yes, technically, much of what we take for granted is partially possible in most other languages, but it is often hard to use, an add-on, an afterthought. But more important, Java developers even do not use debuggers/inspectors/browsers during development, let alone during production. It's just edit/compile/run/crash - add some print statements and run again. During production its all massive plain logging. We can dump live stacks with FUEL for example. On 24 Apr 2014, at 06:01, S Krish <[hidden email]> wrote: > One can easily do that with Java / Eclipse or for VC++ / Visual Studio with attach to process. Probably I would reckon these to be more "secure" as industry prefers rather than having live debug capabilities built in to the code delivered or somehow "in-process". I am sure all others as in python, ruby et als will have debug in prod capabilities if reqd. > > Javascript with Rhino also can easily allow live debug if the reqd jar is present.. > > The bigger purchase Smalltalk gives is in reflection that can be leveraged to produce fairly extensive logger reports which no other langauge currently does when fault occurs in production. > > I doubt in production the industry is as of now willing to let debug be acceptable specially in Banking domain. > > The smalltalk advantages are not translating into business gains per se given the comfort zone of security, safety production systems are wrapped in procedurally. > > > On Thu, Apr 24, 2014 at 7:39 AM, askoh <[hidden email]> wrote: > Smalltalk has the capability of allowing live debugging in production > servers. How unique is this capability? What other systems allow that? > > Is there a name for such capability? Can we coin one and market it? > > What are the pros and cons of having such a capability? > > All the best, > Aik-Siong Koh > > > > -- > View this message in context: http://forum.world.st/Debugging-in-Production-Servers-tp4756136.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > |
|
|
Even in Smalltalk I have seen less capable developers not exploiting even a fraction of the capability Smalltalk has and depend on loggers / prints to transcripts and lot less use of reflection live to inquire and detect issues faster. The issue I explained is that the capability exists and is not exploited due to process constraints in the industry even for Java, so Smalltalk capability will not be seen as a killer feature per se even if its more flexible and capable. The reflection to dump more logger information is of course most welcome but without adding any performance overhead at runtime except when the error occurs. I would further aver that all the Smalltalk capabilities are highly leveraged in a dev environment and is capable of cutting dev time to one third or even lesser in the hands of an expert. On Thu, Apr 24, 2014 at 11:12 AM, Sven Van Caekenberghe <[hidden email]> wrote: I am sorry, but I disagree. |
Re: Debugging in Production Servers
|
|
>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. |
Re: Debugging in Production Servers
|
"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."So the world definitely starts to catch up with Smalltalk. Which can only be a good thing.
On Thu, Apr 24, 2014 at 12:26 PM, Torsten Bergmann <[hidden email]> wrote:
|
Re: Debugging in Production Servers
|
|
Kilon wrote:
>Visual Studio can do this with Edit and Continue I know - but still not comparable. Apples and oranges - you know ;) In VS it works only to a certain extent and has same limits (mostly that in static languages nothing is so late bound as like in dynamic languages): "Edit and Continue handles most types of code changes within method bodies. Most changes outside method bodies, and a few changes within method bodies, cannot be applied during debugging, however." as you can read on MSDN http://msdn.microsoft.com/en-us/library/vstudio/ms164927%28v=vs.100%29.aspx Try to change the debugger in .NET while it is running ;) >So the world definitely starts to catch up with Smalltalk. Which can only >be a good thing. For sure - virtual machines and GC are now common accepted concepts. Java catched up on the tool side with Eclipse as former Smalltalkers laid the ground. (OTI comes to mind). Now even there is a movement to more dynamic environments/languages as JavaScript, Groovy and Dart prove. Unfortunately most of the languages these days are static and still predefined (syntax and facilities) by vendors. Also the runtimes are vendor controlled. And not to forgert: ST concepts like #allInstances would render security concepts like AppDomains in .NET runtime useless, ... Runtimes like .NET or Java catch up these days for better support on dynamic languages (see #dynamicInvoke in JVM). But to run the way you are used to in Smalltalk you need a different base with more control. That's why it is so hard to get Smalltalk with all features and good performance on top of these VMs/runtimes. Contrary the Smalltalk language just sits on top of a dynamic changeable object environment. So if you like you can add new language constucts while running (Traits, Namespaces/Environments, Interfaces, ...) or even new language support (see Helvetica in Pharo). You can change nearly anything (despite the basics in the VM while running). That a SmalltalkVM can run other languages/bytecodes like Java was already demonstrated by VisualAge (IBM) and by Except with Java on top of Smalltalk/X. And just to clarify: Smalltalk has to catch up as well, especially regard better scoping and modularity. That's why Pharo is "Smalltalk inspired". Especially the meta-facilities of Smalltalk are currently not used as they could be used. Especially to do a big part of daily software work nearly automagically ... Bye T. |
Re: Debugging in Production Servers
|
|
In reply to this post by Sven Van Caekenberghe-2
On Wed, Apr 23, 2014 at 10:42 PM, Sven Van Caekenberghe <[hidden email]> wrote: I am sorry, but I disagree. And the crucial linguistic difference is Smalltalk's (and LISP's) resume semantics for exceptions vs Java's restart semantics. This difference is that in Smalltalk the exception handler is executed in the context of the exception, allowing the programmer to see the point of error and provide a value with which to /resume/ execution. In Java the exception is delivered in the context of the handler, discarding the execution state that caused the exception, only allowing the program to /restart/ the code that caused the exception, and making investigating the cause of the exception impossible in the current run.
We can dump live stacks with FUEL for example. And this because Smalltalk provides first-class activation records (contexts) /and/ has resume semantics for exceptions.
best, Eliot
|
|
|
Eliot Miranda wrote:
Thanks for that Eliot. Its very interesting to learn that distinction. cheers -ben |
|
Administrator
|
In reply to this post by askoh
Thanks for all the comments. Let me distilled what I have learned. Correct me if I am wrong.
In Smalltalk: Production environment and development environment are very similar if not identical. Runtime and debug modes are identical. So, debugging is instantaneous available. Debugging occurs at the context of the exception itself - not in a handler or somewhere else. Debugger, nah, the whole environment allows doit's, code changes and resumes always. Reflection is constantly available for debugging and logging. Can we coin a term for these capabilities/properties? Can we define a standard to gauge programming environments? All the best, Aik-Siong Koh |
Re: Debugging in Production Servers
|
|
AFAIK the term is "live coding" meaning the ability to fully code an application while it runs. On Fri, Apr 25, 2014 at 1:01 PM, askoh <[hidden email]> wrote: Thanks for all the comments. Let me distilled what I have learned. Correct me |
Re: Debugging in Production Servers
|
|
In reply to this post by askoh
On Fri, Apr 25, 2014 at 5:01 AM, askoh <[hidden email]> wrote:
> Thanks for all the comments. Let me distilled what I have learned. Correct me > if I am wrong. > > In Smalltalk: > Production environment and development environment are very similar if not > identical. The "environments" on my laptop are the same as my production server? No, one should never count on that. > Runtime and debug modes are identical. So, debugging is instantaneous > available. What about everyone's obsession with shrinking? No one minds a "luxurious" IDE image for development, but most of us seem hell-bent on deploying "minimal" production servers totally stripped of those IDE/debugging luxuries. Now, I'm sure the debugger itself is not stripped, so that's better than nothing, unless running true headless with no way to get a window on the image. We're certainly "able" to do it, but it seems like our desire to shrink might cause need for some balance that provides the best of both worlds.. |
Re: Debugging in Production Servers
|
|
In reply to this post by askoh
On Apr 25, 2014, at 7:01 AM, askoh <[hidden email]> wrote: Thanks for all the comments. Let me distilled what I have learned. Correct me great question, yeah I can validate that for airflowing. Those features allowed us to do hot maintenance more than once At least a couple of times we did it live with a real customer on the other side, it was really great but don’t get too excited, managing a real bug and a real customer's perception both at the same time requires a lot of muscle |
Re: Debugging in Production Servers
|
|
What I found useful is the ability to patch (compile code) in a
running server. That's really a plus when you can't shutdown the server. To me... an interactive debugger in the production environment is not a requirement. Esteban A. Maringolo 2014-04-25 17:38 GMT-03:00 Sebastian Sastre <[hidden email]>: > > > On Apr 25, 2014, at 7:01 AM, askoh <[hidden email]> wrote: > > Thanks for all the comments. Let me distilled what I have learned. Correct > me > if I am wrong. > > In Smalltalk: > Production environment and development environment are very similar if not > identical. > Runtime and debug modes are identical. So, debugging is instantaneous > available. > Debugging occurs at the context of the exception itself - not in a handler > or somewhere else. > Debugger, nah, the whole environment allows doit's, code changes and resumes > always. > Reflection is constantly available for debugging and logging. > > Can we coin a term for these capabilities/properties? Can we define a > standard to gauge programming environments? > > > great question, yeah I can validate that for airflowing. > > Those features allowed us to do hot maintenance more than once > > At least a couple of times we did it live with a real customer on the other > side, it was really great but don’t get too excited, managing a real bug and > a real customer's perception both at the same time requires a lot of muscle > > sebastian > > o/ > > |
Re: Debugging in Production Servers
|
|
On 25 Apr 2014, at 22:40, Esteban A. Maringolo <[hidden email]> wrote: > To me... an interactive debugger in the production environment is not a requirement. Hmm, but that _is_ a key point: often being able to 'look into a running server' to find or investigate a problem makes all the difference - this interactivity can be much more productive than trying fixes blind. |
Re: Debugging in Production Servers
|
|
2014-04-25 17:48 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
> > On 25 Apr 2014, at 22:40, Esteban A. Maringolo <[hidden email]> wrote: > >> To me... an interactive debugger in the production environment is not a requirement. > > Hmm, but that _is_ a key point: often being able to 'look into a running server' to find or investigate a problem makes all the difference - this interactivity can be much more productive than trying fixes blind. I value a nice stack dump or a FUEL dump (I haven't tried this), to recreate the context. I understand the fact that "a similar error context" is not the same as "the actual error context", but the truth is if the error is related with I/O (files, network, db...) it is not going to be simple to fix, and maybe the dependent party (a client on the other side) is already gone. That's why I said that, for me (emphasis here), it isn't a requirement, particularly to fix bugs. For live inspection and modifications I DO FIND it valuable. Esteban A. Maringolo |
Re: Debugging in Production Servers
|
|
In reply to this post by Sven Van Caekenberghe-2
On Apr 25, 2014, at 5:48 PM, Sven Van Caekenberghe <[hidden email]> wrote: look into a running server' to find or investigate a problem makes all the difference yeah, I agree. Logs are the last resource and hot debugs are unbeatable. They can cut costs a lot when investigating in the real environment where the problem happens and Smalltalk’s debugger is the closest thing to a developer-with-problem dream-tool that the industry can give. |
|
|
I've quite often opened a REPL on Rails apps in the production environment. You can basically execute everything on the production environment. This is quite useful for checking what's going on (usually a mismatch between your development/staging environment and the production one). Beware that you do not connect to the serving process that your customer is seeing. You just spin a new REPL process with the production settings. And frankly it was usually more than enough to find what you need to fix.On Fri, Apr 25, 2014 at 11:18 PM, Sebastian Sastre <[hidden email]> wrote:
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |