Writing configurations by hand can be a drag. But fear not! Dale and Co. have created an API to facilitate your workflow.

Photo by http://www.flickr.com/photos/tkellyphoto/4507543643/a> / CC BY-NC-ND 2.0

One of the harder problems that developers have to deal with is characterizing issues that show up only in production, especially if exceptions aren’t being thrown.

In development, you’d just toss a `self halt` or two into the code and you’d be off to the races, but in production where multiple servers are involved, things can get a little more complicated. Often developers must resort to print statement debugging and sophisticated server log mining tools to characterize production issues.

Remote Breakpoints to the Rescue

Breakpoints have been available in GLASS, for a long time now. In 2008 I added remote breakpoints for Seaside2.8 and finally with the release of Seaside 3.0.6.3, remote breakpoints are available for Seaside 3.0.

With remote breakpoints, you can easily set/clear breakpoints in all of the gems that are serving Seaside and when a breakpoint is encountered a continuation is snapped off and added to the ObjectLog. At your leisure, you can debug the continuation from GemTools or inspect the continuation via the ObjectLog.

Step by Step Guide to Remote Breakpoints for Seaside 3.0

1. Setup for Remote Breakpoints:
   1. GemStone/S 2.x
   2. GemStone/S 3.x
2. Launch Seaside
3. Testing, Testing…:
   1. Set Remote Breakpoint
   2. Trigger Breakpoint with WARemoteDebuggingWalkbackErrorHandler
   3. Trigger Breakpoint with WAGemStoneProductionErrorHandler
   4. Debug Breakpoint in GemTools
   5. View Breakpoint in ObjectLog
   6. Clear Remote Breakpoints

Setup for Remote Breakpoints

Before using remote breakpoints, you need to do a little prep depending upon which version of GemStone/S you are using.

1. GemStone/S 2.x
2. GemStone/S 3.x

Remote Breakpoint Setup for GemStone/S 2.x

If you want to use remote breakpoints with GemStone/S 2.x, you need only install a new StartSeaside30 Adaptor script or add the following section to your own script:

true "enable for remote breakpoints and profiling"
  ifTrue: [
    GemToGemAnnouncement installStaticHandler.
    Exception
      installStaticException: [:ex :cat :num :args |
          BreakpointNotification signal.
          "needed to avoid infinite loop when resuming
           from a breakpoint"
          ex _incrementBreakpointsToIgnore. ]
      category: GemStoneError
      number: 6005
      subtype: nil.
   System commitTransaction
      ifFalse: [
         nil error: 'Could not commit for GemToGemSignaling' ]].

Remote Breakpoint Setup for GemStone/S 3.x

The script support for remote breakpoints is preinstalled in GemStone/S 3.0.1, however you must disable native code by setting GEM_NATIVE_CODE_ENABLED to FALSE in your gem conf files:

GEM_NATIVE_CODE_ENABLED = FALSE;

In 3.x there are actually three conf files to think about:

1. $GEMSTONE/seaside/data/system.conf
2. $GEMSTONE/seaside/etc/seaside30.conf
3. $GEMSTONE/seaside/etc/maintenance30.conf

By default, GEM_NATIVE_CODE_ENABLED is set to FALSE, but in a production installation you should set GEM_NATIVE_CODE_ENABLED to TRUE to get the best performance and only set it to FALSE if you want to enable remote breakpoints.

Launch Seaside

1. Start up a GemTools development image.
2. Specify the adaptor and number of Seaside server gems to be used (note that the Seaside30 session workspace also has the necessary template expressions).
3. Start the Seaside server gems.

Testing, Testing…

Lets run through the process of using remote breakpoints:

1. Set Remote Breakpoint
2. Trigger Breakpoint with WARemoteDebuggingWalkbackErrorHandler
3. Trigger Breakpoint with WAGemStoneProductionErrorHandler
4. Debug Breakpoint in GemTools
5. View Breakpoint in ObjectLog
6. Clear Remote Breakpoints

For this example we’ll set a breakpoint in the WAExceptionFunctionalTest>>raiseWarning method.

Set Remote Breakpoint

1. If you’ve just started your Seaside gems for this test, then you should force a transaction by selecting either the ‘Commit’ or ‘Abort’ menu item on the GemTools Transaction menu. The list of running Seaside gems is maintained in a persistent list and the action for starting the gems from GemTools doesn’t involve a transaction. If there is no commit or abort between the time you’ve started the Seaside gems and set the breakpoint, the breakpoint will not be set in the Seaside gems.
2. In the GemTools development image, bring up a class editor on the WAExceptionFunctionalTest>>raiseWarning method, place the cursor at the beginning of the #notify selector and select the ‘set breakpoint’ menu item:
   

Trigger Breakpoint with WARemoteDebuggingWalkbackErrorHandler

1. Bring up a web browser on the WAFunctionalTest page:
   http://localhost:8383/tests/functional/WAExceptionFunctionalTest
2. Ensure that you are using either the WARemoteDebuggingWalkbackErrorHandler or WAGemStoneProductionErrorHandler by selecting the correct class from the error handler drop down list (don’t forget to click on the ‘Set Handler’ button):
3. Trigger the breakpoint by clicking on the ‘Raise warning’ link:
4. The Seaside Walkback page will come up:
5. Click on the ‘Remote Debug’ link to snap off a continuation add it to the ObjectLog:
   
6. The remote debug page will come up, confirming that the breakpoint continuation has been added to the ObjectLog:

Trigger Breakpoint with WAGemStoneProductionErrorHandler

1. Go back to theWAFunctionalTest page and select the WAGemStoneProductionErrorHandler this time:
2. When you trigger the breakpoint clicking on the ‘Raise warning’ link, instead of a walkback window you get the production error message window for the Warning that is signaled as part of the functional test:
3. This pages is what you’d expect without the breakpoint, but since you are using the WAGemStoneProductionErrorHandler, the breakpoint continuation is snapped off and silently added to the ObjectLog along with a continuation for the Warning exception. We can check that by looking at the Debug menu in GemTools:

Debug Breakpoint in GemTools

1. In GemTools use the Debug menu to select the breakpoint continuation:
2. and bring up the debugger on the continuation:

View Breakpoint in ObjectLog

You can inspect continuations in the ObjectLog from your web browser by using the WAObjectLog component.

1. Register the component by following the instructions on the ObjectLog page in the wiki.
2. Hit http://localhost:8383/tools/objectLog in your web browser to bring up the Object Log page:
3. Scan the list and find the item labeled ‘continuation’ and click on the ’2′ link:
4. When you click on the ’2′ link you are taken to an object inspector on the ObjectLogEntry itself. From there you can navigate to the objects stashed in the entry:
5. To view a printString of the stack click on the ‘ GsProcess(oop=206376961, status=debug, priority=15, WARemoteDebuggingWalkbackErrorHandler >> open:’ link:
6. This page doesn’t provide as much information as the debugger view, but sometimes a stack trace is enough:
   

Clearing Remote Breakpoints

1. To clear the breakpoints, you can bring up the text menu and select ‘clear ALL breakpoints’ to clear all of the breakpoints that may be set or ‘clear method breakpoints’ to clear the breakpoints that are set in the selected method:

—–
[1]http://www.flickr.com/photos/mwichary/2356597072 / CC BY 2.0

• CofigurationOfSeaside30 3.0.6.3

This release is primarily aimed at supporting GemStone/S 3.0.1 with several GemStone-specific bugfixes and a couple of GemStone-specific Seaside bugfixes:

• Issue 636: expected exception behavior WAWalkbackErrorHandler not portable (and not ANSI compliant)
• Issue 694: Swazoo adapter does not respect Request URIs ending in slash

With this release I have finally implemented remote breakpoints for Seaside 3.0 which will be covered in a separate blog post.

Photo by http://www.flickr.com/people/halfanacre / CC BY-NC-ND 2.0

GLASS 1.0-beta.8.7.1 has been released. There are only a couple of bugfixes in this release as this release was targeted at the upcoming GemStone/S 2.4.5 release. The bulk of the changes were related to porting GLASS 1.0-beta.8.7 to GemStone/S 2.4.5.

GLASS 1.0-beta.8.7.1 has been tested against GemStone/S 2.3.1, GemStone/S 2.4.4.1, GemStone/S 3.0.1 and the forthcoming GemStone/S 2.4.5 release.

To upgrade to GLASS 1.0-beta.8.7.1:

1. Update your GemTools image to GemTools 1.0-beta.8.6.
2. Update GLASS to 1.0-beta.8.7.1.
3. Make a backup.

—–

[1]http://www.flickr.com/photos/delgrossodotcom/3698511651 / CC BY-NC-SA 2.0

I spend a lot of time building my own images.

If I am downloading hundred of images every day, an image can last me a maximum of a couple of days, and I spend a lot of time building my own images, then there is something that it is not working.

Moreover, I am lazy, I don’t like loosing time with it, and my memory is bad. Hence, I have come to the solution that I will show you in this post.

Photo by http://www.flickr.com/photos/addictive_picasso/561134034 / CC BY 2.0

GemTools 1.0-beta.8.6 has been released. With this release the GLASS upgrade process has been improved, yet again.

One-Click 1.0-beta.8.6 GemTools

One-Click GemTools images are available on the GLASS downloads page. GemTools images are available for use with GemStone/S 2.3.x, GemStone/S 2.4.4.x, and GemStone/S 3.0.1.x,

GLASS Upgrade Cha Cha

I suppose it is a little known fact that the GemTools code base includes code that is used to drive the GLASS upgrade process, although my constant entreaties to “upgrade GemTools to the latest version before upgrading GLASS” may have given you a clue or two.

I thought I’d take this opportunity to describe what goes on behind the scenes when you select the  Update > Update GLASS menu item in GemTools. This section should be especially useful if you prefer to upgrade your system without running GemTools.

For a complete upgrade script, take a look at the GLASS upgrade script page on the glass db wiki. The GLASS upgrade script page will always have the latest and greatest upgrade script.

Through the ‘Update GLASS’

The upgrade process has been greatly simplified since I first started using Metacello for bootstrapping GLASS 1.0-beta.0, back in November of 2009, but the basic steps have remained the same:

1. bootstrap the latest version of Metacello
2. bootstrap the latest version of Monticello
3. upgrade GLASS

Bootstrap Metacello

Currently Metacello 1.0-beta.31.1 is the version that is needed for a smooth upgrade process:

ConfigurationOfMetacello project currentVersion versionNumber < '1.0-beta.31.1' asMetacelloVersionNumber ifTrue: [
        (Gofer new)
            gemsource: 'metacello';
            version: 'Gofer-Core.gemstone-dkh.135';
            version: 'Metacello-Base-DaleHenrichs.19';
            version: 'Metacello-Core-dkh.468';
            version: 'Metacello-MC-dkh.531';
            version: 'Metacello-Platform.gemstone-dkh.23';
            load ].

It turns out that the best formula for bootstrapping Metacello is to directly load the key packages. I would have liked to use Metacello to bootstrap itself, but for GLASS we need to upgrade a wide range of Metacello releases dating back to over a year ago and there are several bugs that make it impractical to do anything but load the packages directly.

Bootstrap Monticello

To bootstrap Monticello, we use the GLASS configuration and load the ‘Core’ and ‘Monticello’ projects:

MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [[[
    (ConfigurationOfGLASS project version: '1.0-beta.8.7.1')
        load: #( 'Core' 'Monticello' )
]
    on: MetacelloSkipDirtyPackageLoad
    do: [:ex | ex resume: false ]]
        on: Warning
        do: [:ex |
            Transcript cr; show: ex description.
            ex resume ]].

We wrap the load with an out-of-memory handler.

The MetacelloSkipDirtyPackageLoad handler is there to compensate for a bug in the Monticello package loader that occasionally resulted in a package being marked dirty after a successful load.

The Warning handler is also there to ensure that packages needed for the upgrade are loaded whether or not they are marked dirty.

Upgrade GLASS

The GLASS upgrade is completed by doing a simple load:

MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [[[
    (ConfigurationOfGLASS project version: '1.0-beta.8.7.1')
        load
]
    on: MetacelloSkipDirtyPackageLoad
    do: [:ex | ex resume: false ]]
        on: Warning
        do: [:ex |
            Transcript cr; show: ex description.
            ex resume ]].

—–

[1]http://www.flickr.com/photos/archer10/5228946002 / CC BY-SA 2.0

GemStone 3.0.1

GemStone/S 64 3.0.1 was released on Monday of this week.GemStone/S 64 Bit 3.0.1 is a new version of the GemStone/S 64 Bit object server. This release provides feature enhancements and fixes a number of serious 3.0 bugs.

Release notes, Install Guide and manuals are available here. Be sure to carefully read the GemStone 3.0.0 release notes, if this is the first time you have used GemStone/S 3.0 as there are significant differences between GemStone3.x and GemStone 2.x

GLASS 1.0-beta.8.7

GemStone 3.0.1 ships with GLASS 1.0-beta.8.7 pre-installed in $GEMSTONE/bin/extent0.seaside.dbf.

Currently there is no path for upgrading a GemStone 2.x GLASS application to GemStone 3.0.1. The upgrade path will be defined in a future release.

If you are running a production application in GemStone 2.x, it is recommended that you continue to use GemStone 2.x for production. You should port your application to GemStone 3.0.1 in preparation for the time when the upgrade procedure is defined.

If you are starting a new application then you should use GemStone 3.0.1 as a starting point.

Download and Installation

You can download the binaries from ftp://ftp.gemstone.com/pub/GemStone64/3.0.1/ or visit seaside.gemstone.com downloads page and use the installGemStone3.0.1.sh script to download and install GemStone 3.0.1 on your machine (highly recommended).

Starting a 3.0.1 stone

Once you’ve installed Gemstone in /opt/gemstone/product, follow these steps to start and stop the stone:

1. Define GEMSTONE environment variables  ($GEMSTONE/bin and $GEMSTONE/seaside/bin added to your $PATH environment variable):

   source /opt/gemstone/product/seaside/defSeaside

   It is recommended that you add this step to your .bashrc.

2. Copy the system.conf and GLASS extent0.dbf files to data directory:

   cp $GEMSTONE/seaside/system.conf \
       $GEMSTONE/seaside/data
   chmod +w $GEMSTONE/seaside/data/system.conf
   cp $GEMSTONE/bin/extent0.seaside.dbf \
       $GEMSTONE/seaside/data/extent0.dbf
   chmod +w $GEMSTONE/seaside/data/extent0.dbf

   This step is performed as part of the installGemStone3.0.1.sh script.

3. Start netldi and stone processes:

   startnet
   startGemstone

4. Ensure stone process is running:

   gslist -lcv

5. Stop stone process:

   stopGemstone

Check the Starting a stone page on the glass db wiki for updates to the above procedure.

GemTools 1.0-beta.8.5

A One-Click GemTools 1.0-beta.8.5 for GemStone 3.0.1 can be obtained from the seaside.gemstone.com downloads page or you can download GemTools 1.0-beta.8.5 for Gemstone/S 3.0.1 all platforms directly.

You can build a custom GemTools image by following these steps on the glass db wiki.

Seaside 3.0, Magritte 2.0, and Pier 2.0

I have new releases of Seaside, Magritte and Pier that have been ported to GemStone 3.0.1 queued up and they should be made available shortly.

—–

[1] “Mike” Michael L. Baird, flickr.bairdphotos.com / CC BY 2.0

GLASS 1.0-beta.8.7 has been released. I’ve been pretty busy since the last GLASS release in March: there are almost 50 bugfixes included in this release.

GLASS 1.0-beta.8.7 has been tested against GemStone/S 2.3.1, GemStone/S 2.4.4.1 and the forthcoming GemStone/S 3.0.1 release.

I plan a series of blog posts over the next few weeks to cover some of the more interesting changes and new features included in and enabled by GLASS 1.0-beta.8.7.

GemStone/S 2.3.1 Upgrade

If you’ve downloaded the GLASS appliance, you will be running on GemStone/S 64 Version 2.3 and GLASS.230-dkh.164. The good news is that you can upgrade from GLASS.230-dkh.164 to GLASS 1.0-beta.8.7:

1. Update your GemTools image to GemTools 1.0-beta.8.5.
2. Update GLASS to 1.0-beta.8 which gets you to the point where Metacello is installed. This step can take awhile, so be patient.
3. Update GLASS to 1.0-beta.8.7.
4. Update the rest of the projects that were part of  GLASS.230-dkh.164, most notably:
• Seaside 2.8.5
• Magritte 1.2.1.5
• Pier 1.2.1.6

As always don’t forget to make a backup before and after the upgrade.

GemStone/S 2.4.4.1 Upgrade

GemStone/S 2.4.4.1 and the subsequent 2.4.x releases have all shipped with GLASS 1.0-beta.8.1 pre-installed in the seaside extent ($GEMSTONE/bin/extent0.seaside.dbf). The upcoming GemStone/S 2.4.5 release will be shipped with GLASS 1.0-beta.8.7 pre-installed.

To upgrade to GLASS 1.0-beta.8.7:

1. Update your GemTools image to GemTools 1.0-beta.8.5.
2. Update GLASS to 1.0-beta.8.7.
3. Make a backup.

—–
http://www.flickr.com/photos/mcbridejc/6165651180 / CC BY-NC-SA 2.0

GemTools 1.0-beta.8.5 has been released. With this release there have been several bugfixes:

• Issue 132 : Use System class>>#”cacheName:” to make session recognizable in vsd
• Issue 250 : order and size of args asociated with #halt changed in Gci3xErrStype64 (GemStone 3.0)
• Issue 280: GemTools login error: ”Network error – text follows”, does not follow with error message…
• Issue 291: Maintenance Gem Topaz Exit 3.0 / GemStone 3.0

as well as some tweaks to the GLASS upgrade process.

Upgrades

I always recommend that you update GemTools before upgrading GLASS, because the GLASS upgrade process is driven by code included in GemTools. When you select the Update GLASS menu item, the class OGUpgradeJadeServer (included in the GemTools distribution) is compiled on the server and is then used to control the upgrade process.

Speaking of upgrading GLASS… If you are interested in doing a GLASS upgrade from a topaz script take a look at this page on the glassdb wiki has the most up-to-date instructions.

Help

Don’t forget that when you load GemTools into Pharo and Squeak, a set of Help Browser pages are created to provide the most up-to-date information on getting started with GemStone and the GemTools image.

Pharo

Before releasing 1.0-beta.8.5, I tried loading GemTools into some of the more recent Pharo releases, like Pharo 1.3 and Pharo 1.2, but unfortunately the OmniBrowser implementation in those images is incompatible with the OmniBrowser required for GemTools. The latest version of Pharo that I found that works with GemTools is Pharo1.1.2-11422.

Squeak VM versions

While we’re on the subject, you should also be aware that in order to connect to GemStone, you must use an older version of the Squeak vms (4.2.2 or older) to avoid an FFI bug. For more details, see Issue 258.

—–
http://www.flickr.com/photos/nhankamer/5616046050 / CC BY-NC 2.0

Metacello 1.0-beta.31 has been released. The primary motivation for the release is support for GLASS 1.0-beta.8.7:

• Use Gofer 1.0.5.1 which addresses some GemStone problems.
• GemStone  variant of the fix for Pharo Issue 4613: programmatic calculation of platform attributes.

and change that affects the sort order for branched Monticello packages:

In previous versions, the branch name took precedence over the version number when sorting Monticello packages. This had the effect of preventing branched Monticello packages from being loaded on top of a non-branched Monticello package which is not correct. Moving forward the version number takes precedence over the branch name and the branch name is only used to break a version number tie.

—–

[1] Photo by http://www.flickr.com/photos/ucumari/1335533357 / CC BY-NC-ND 2.0