info.michael-simons.eu

Grails: Completely disable stacktrace.log file

Regarding my question on twitter about completely disabling the creation of stacktrace.log from a Grails application in production mode, here is my answer:

environments {
    production {
        log4j = {
            appenders {
               null name:'stacktrace'
            }
        }
    }
    development {
    }
}

Be careful: This overwrites all other log4j closures that are made outside the environment specific settings. I found no solution for that.

Background: One of my Grails 1.1 app fails to start on a Tomcat application container deployed on an Oracle Enterprise Linux server because it fails to create the stacktrace.log.

What annoyed me is that i needed to dig around in the Grails source code to find the answer to my question in “src/groovy/org/codehaus/groovy/grails/plugins/logging/Log4jConfig.groovy” within the method “createFullstackTraceAppender()”. Should be stated in the documentation (perfect place here).

Edit: If your Grails 1.1 still fails to start(*) look out for xercesImpl.jar and xml-apis.jar or similar somewhere in your Tomcat 5 directory. These are some kind of Java 1.4 compatibility layers which break things in Grails 1.1. Oracle puts these into common/endorsed. After removing them, everything went fine.

(*) Exception was:

java.lang.RuntimeException: XPathFactory#newInstance() failed to create an XPathFactory for the default object model: 
http://java.sun.com/jaxp/xpath/dom with the XPathFactoryConfigurationException: javax.xml.xpath.XPathFactoryConfigurationException: 
No XPathFctory implementation found for the object model: http://java.sun.com/jaxp/xpath/dom

Filed in English posts | Comments (7) »

Phusion Passenger and memcache-client revisited

The last Passenger update brought some good explanation off the problems regarding Passenger and memcache-client (see here).

Smart spawning of Passenger processes creates shared file descriptors. As the connections to memcached are sockets they are shared as well so data on them gets corrupted which is explained very nicely in the Passenger documentation: Example 1: Memcached connection sharing (harmful).

The solution presented there works like a charm. The reestablish_connection_to_memcached line is actually not more than CACHE.reset where CACHE is the reference to the memcache connection.

After that change, spawning methods smart-lv2 and smart will work in connection with environment.rb configured memcache connections.

Edit: As requested in the comments, a little example:

memcache_options = {
  :c_threshold => 10000,
  :compression => true,
  :debug => false,
  :namespace => 'some_ns',
  :readonly => false,
  :urlencode => false
}
 
CACHE = MemCache.new memcache_options
CACHE.servers = '127.0.0.1:11211'
begin
   PhusionPassenger.on_event(:starting_worker_process) do |forked|
     if forked
       # We're in smart spawning mode, so...
       # Close duplicated memcached connections - they will open themselves
       CACHE.reset
     end
   end
# In case you're not running under Passenger (i.e. devmode with mongrel)
rescue NameError => error
end

In this case, CACHE is the global constant that i use to access my memcache-client.

I guess you’ll need to do the same with the global Rails.cache object, but i’m not sure. Anyway, the above solution works for me.

Filed in English posts, Rails | Comments (35) »

Grails’ withFormat block

Some things are not really different in Rails and Grails world. The pendant to Rails’ respond_to method is Grails withFormat block.

Both are supposed to render a different content type as requested according to the accept header and and the format parameter.

And both fail to some extend with Internet Explorer 5.5 to 7.0. For a longer explanation see my post on respond_to linked above. In short: First visit always gave me the an Excel File, all subsequent visits the intended html page.

I used nearly the exact solution within Grails 1.0.4 as in Rails:

withFormat {
      xls {
        // Same crap with IE 6/7 as with rails, compared to
        // http://info.michael-simons.eu/2007/08/06/rails-respond_to-method/
        if(params.format == 'xls') {
          def df = new SimpleDateFormat("yyyy-MM-dd")
 
          def report = ExcelReport.findById(params.reportId)          
          if(report == null)
            report = ExcelReport.findByBezeichnung('Absatzprognose')          
 
          response.contentType = 'application/vnd.ms-excel'
			    response.setHeader("content-disposition", "attachment;filename=some_filenname.xls")
          excelService.runExcelReport(
            report.bezeichnung,
            "some_parameter",
            response.outputStream
          )
          return
        }
      }
    }

Grails 1.1 seems to have fixed some issues on this case and a default or empty html {} block in front of any other format like so will do the trick:

withFormat {
      html {
        // depending on your needs
      }
      xls {
        // funny excel stuff
      }
    }

Filed in English posts | Comments (0) »

Wütend

Oh man, ich bin so verdammt wütend, ein Tweet reicht nicht aus.

Es ist so zum kotzen, dass es Programmiersprachen wie PHP den Leuten so leicht machen, hübsche Sachen zu programmieren, die auseinander fallen, wenn man sie mal schief anschaut.

“Hübsche Gui” und “Ich weiß, was ich da gerade in die Datenbank schreibe” sind zwei Paar Schuhe.

Wie kann man eigentlich eine Checksum Routine so implementieren, dass sie auf unterschiedlichen Architekturen unterschiedliche Ergebnisse liefert? Braucht es da mehr als einen mittelmässig begabten Affen, zu erkennen, dass das eine scheiß Idee ist? Und noch spannender ist es natürlich dann, diese Funktion auch zu nutzen.

Boah echt ey.

Leute, lasst die Finger von PHPs crc32() Implementierung oder benutzt sie richtig.

Filed in German posts | Comments (0) »

Frustration

if you want something done right, do it yourself

If you happen to use the mint tracking tool like me, be careful when migrating from a 32bit to a 64bit server or vice versa. Mint saves ip addresses and a buttload of checksums as signed long values. That bites you right in the ass when the first visitors starts arriving at your site. All from 127.255.255.255, or at last visitors with an ip starting with > 127.

If you read this post before migrating, just add the following to your migration:

ALTER TABLE mint_visit 
  MODIFY COLUMN `ip_long` BIGINT NOT NULL,
  MODIFY COLUMN `referer_checksum` BIGINT NOT NULL,
  MODIFY COLUMN `domain_checksum` BIGINT NOT NULL,
  MODIFY COLUMN `resource_checksum` BIGINT NOT NULL,
  MODIFY COLUMN `session_checksum` BIGINT NOT NULL;
 
ALTER TABLE mint_debugger   
  MODIFY COLUMN `ip_long` BIGINT NOT NULL;
 
ALTER TABLE mint_geo  
  MODIFY COLUMN `ip` BIGINT NOT NULL;
 
ALTER TABLE mint_hostnames  
  MODIFY COLUMN `ip_long` BIGINT NOT NULL;

and you’re done.

If it’s too late, change your tables as well. You then also have to delete your entire mint_visit data, as the records are already corrupted. Great fail.

However, why on earth store an ip address as a long value?!? It’s an ip address and if i want to look at it, the program needs to go the other way round. To me: It’s just stupid fucking with datatypes and problems as that is what you get if you do so. It maybe makes sense for computation of networks, but not for a statistic tool. At least, i don’t see any sense in this.

Actually, the problem is known.

Filed in English posts | Comments (1) »