Tip: Service Studio is not always stopping in my breakpoints (Debugger)

Tip: Service Studio is not always stopping in my breakpoints (Debugger)

  
Hi everyone,
 
I am writing this post to talk about some common causes we have seen from time to time for erratic behaviors when using the Service Studio Debugger.
 
Symptoms
User activates the Service Studio debugger for an opened eSpace and a lot of times his breakpoints will either fail to trigger or, when they do, stepping through the code may hang the debugger.

 
Causes / Solutions
There are three common causes that could explain this sort of "erratic" behavior with the Debugger (in .Net OutSystems Platform installations):
 
  • The first one is if the server you are connecting through Service Studio is running a Web Garden in IIS (multiple worker processes for one Application Pool). The debugger will not work correctly with Web Garden since debug information is stored in the worker process memory and you have no guarantees that your requests will always be served by the same process.
    In systems where you want to debug you must turn off Web Garden in IIS (set number of Worker Processes per Application Pool to 1).
     
  • Note that the above also happens if you are running your development environment in a farm setup (meaning - with multiple front-ends behind a load balancer). In these setups, if you cannot guarantee that one individual user will always connect to the same front-end; since all information on the debug session is kept in memory, it is not possible to debug. 
    To use a farm setup for development, your load balancer must be set to redirect specific users to a front-end based on something immutable. It cannot be a session cookie (like it's usually done for runtime applications). Using the source IP may be possible if the end-user IP is visible by the load balancer.
    Alternatively, instead of using a load balancer, distribute users by the front-ends "manually": give them distinct servers to connect to, or use DNS load balancer so users in different areas of the company connect to different servers.
     
  • Another one, also related to IIS, is if you are experiencing Application Pool Recycling events while you are in the middle of a debugging session. If a request that is being debugged is interrupted because of such an event, it is unpredictable what may happen to the debug session.
    To verify if Recycling events are happening you can check the Windows Event Viewer logs of your Platform Server. One common cause for these is a mis-configured set of Application Pool memory limits in IIS (with "maximum memory" settings too low). Verify that these Application Pool settings follow the recommendations made in the OutSystems Platform Server Installation Checklist, under the sections named "Tuning Internet Information Services" (you can access the Installation Checklist by running the Platform Server .Net installer, even if you don't go through the full installation process).

The above 3 topics are all related to one common cause: the fact that information on debug in stored in the memory of the application server. If Service Studio cannot always connect to the same process, it will not see the debug session information, and will assume that the session "died".

Another different problem is:
 
  • When multiple developers are debugging the same eSpace Public Area concurrently. This sort of behavior is felt if the network setup (with proxies/routers in the way) makes the developers’ Service Studio debugging requests reach the development server with the same IP (for example, if a reverse proxy masks the original IP and all requests arrive at the application server as if they came from the proxy itself).
    In this scenario it is not possible for the OutSystems Platform do distinguish between each user and the outcome is undetermined (the user that made the request may not be the one to which the breakpoint hit is reported to), or not.
    If this is the case, you should revise your network setup to make sure that each individual developer's Service Studio reaches the Platform Server with a different IP. There is no other way around this limitation.


 
Cheers!
 
João Proença
 
Hi all

As an alternative to item 3 (multiple developers) you may also opt for using Personal Test Areas for debugging purposes.

 http://www.outsystems.com/help/servicestudio/8.0/eSpace_Life_Cycle/About_Personal_Area.htm

Regards,
Acácio
Starting on OutSystems Platform 9.0.1.15 and 8.0.1.43, there's a new setting that might help if your debugger is not working properly.
Check out this post.