Here is a little technique for indexing JavaScript exceptions in your production and development environments using Splunk.

In JavaScript create an onerror event handler that makes an HTTP request to a server that has access logs indexed by Splunk.

    function JSErrorLogger(httpBeacon){
        var self = this;
        self.handler = function(msg, url, line){
            var log = {
                "date":new Date(),
                "type":"jserror",
                "line":line,
                "msg":msg,
                "url":url
            }
            var logStr = "";
            for(var i in log){
                logStr += i + ":" + log[i] + ” “;
            }
            var imgObj = new Image();
            imgObj.src = httpBeacon + “?” + logStr;
        };
        self.JSErrorLogger = function(){
            window.onerror = self.handler;
        }();
    }

Make sure that this JavaScript is the very first item executed by the interpreter, ensuring all exceptions are caught by the event handler.

Instantiate the class with a URI that points to a beacon on a machine that has Splunk indexing the access log. You may want to set some environment variables in JavaScript that turn logging on for only testing and production machines.

   //if environment test or production
   var splunkJSErrorIndexer = new JSErrorLogger("http://somedomain.com/beacon.gif");

That’s it, now you can empirically understand JavaScript exceptions being raised, set blackberry alerts and correlate ui stability issues to deploys:)

Happy JavaScript Monitoring!

More information can be found in these videos:

• A quick walkthrough of the new preview release feature Live Tail, its UI, and some sample code - See Video
• An overview of the architecture used to integrate real-time data from Splunk Live Tail in a web browser. Challenges and workarounds when using JavaScript/Flash hybrids - See Video

Happy Streams!

Unfortunately, this week we ran into a rather tricky memory leak when using this nifty class. An event listener was subscribed to the progress event and over time memory usage steadily increased to a point of making the browser inoperable.

After a little digging we narrowed the problem down to the URLStreams usage of the ByteArray. It seems as if URLStream was reallocating a buffer for the array and the short turn around time (on the reads) was not giving the garbage collector enough time to throw out the old allocation.

The way the leak could be corrected was by deleting the ByteArray (Set null), forcing garbage collection of the read buffer.

Here is the workaround:


var bytes:ByteArray = new ByteArray();
this.readBytes(bytes, 0, this.bytesAvailable);
bytes = null;


Happy Streams!

Now this is going to sound pretty circa 98, but several main stream browser plugins support a JavaScript communication layer. According to the Millward Brown survey plugin installations of Flash (99%) and Java (85%) are pretty ubiquitous.

Flash/JavaScript Communication
The Flash ExternalInterface class enables communication between JavaScript and the Flash Player. ExternalInterface was first introduced in ActionScript 1.0; so Flash Player 8 is the minimum plugin version required.
From JavaScript

• Call an ActionScript function
• Pass arguments
• Return a value to the JavaScript callee

From ActionScript

• Call a JavaScript function
• Pass arguments
• Pass various data types (Boolean, Number, String, etc…)

Java Applet/JavaScript Communication
The scarcely documented LiveConnect API provides JavaScript with the ability to call methods of Java classes and vice-versa. Using LiveConnect in applets requires the mayscript attribute and the plugin.jar package for newer versions of Java (Howto for Mac OS X users). Communication from Java to JavaScript is mitigated through the netscape.javascript.JSObject class. JavaScript exceptions in Java can be handled using the netscape.javascript.JSException class. Public methods in an applet can be called using the applet container object followed by the method name and arguments (e.g., document.getElementById(”myapplet”).publicAppletMethod(arg1, argN);).

From JavaScript

• Call a Java method
• Pass arguments
• Return a value to the JavaScript callee

From Java

• Call a JavaScript function (Note: does not seem to support deep objects obj.foo(arg))
• Pass arguments
• Pass various data types (Boolean, Number, String, etc…)

It looks like LiveConnect is due for an overhaul in the near future, so you may want to keep your eyes out for changes on Mozilla developer Josh Aas’s blog.

What’s Next
With the power of Java and Flash this opens up the arena for creating visually hidden gateways (i.e., width:0px; height:0px; applets or swf movies) that extend the browser. Stay tuned for the next part in this series where we make a sample application. Feel the power!