donderdag 19 april 2012

Assigning static ip addresses in VMWare Fusion

I'm using VMWare Fusion on my laptop, even though I regret not being able to use the power of Vagrant with VirtualBox, the combination with puppet suits allows me to do reach something similar.
However latest releases of Fusion seemed to have forgotten about the which allowed you to restart your the vm's DHCP server after assigning static ip's to some mac addresses.

Apparently the new approach is:

/Applications/VMware --stop
/Applications/VMware --start
and yes, just a shell script to restart your dhcpd or sending a signal would have been better, but the extensions need to be loaded in a certain order apparently.

vrijdag 4 november 2011

Upgrading to Ubuntu 11.10 with Oracle 11 XE

Well it's been **very** busy times since the last time I've posted something here. Anyways, I've installed Oracle XE 11 pretty much the day it came out (4/sep/2011) and I've been pretty happy with it since then. Since it was running on ubuntu 11.04 and Ubuntu released a newer version (11.10), I thought let's upgrade since it's pretty much a no brainer with ubuntu (do-release-upgrade and you're good to go). But then things went south...

When restaring the VM oracle didn't seem to be there. Yes the listener was there, but that was about it. Where did the database go?

hmm let's see

Connecting on the machine itself with an sql*plus

ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory
Process ID: 0
Session ID: 0 Serial number: 0

Ok, maybe it just didn't autostart for some reason.

> su -l oracle

> sqlplus / as sysdba

SQL*Plus: Release Production on Thu Nov 3 21:42:28 2011

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup
ORA-00845: MEMORY_TARGET not supported on this system


Memory_target is the new (well since oracle 11) in any case to handle it's memory. instead of defining your PGA and SGA separately you just tell oracle that it can use so much memory and it'll try to determine for itself what the correct ratio for your instance should be. Except now...

Apparently one of the big changes for ubuntu 11.10 was that they've moved away from the /var/run, /var/lock and /dev/shm which oracle used for determining how much shared memory you had. So now you've got 0 bytes of (shared) memory as far as oracle is concerned...

Currently there are 2 workarounds for it:
* modify the binary oracle executable (I'd rather not, thank you)
* tell oracle what ratio to use instead of letting it figure it out for itself.

So latter approach seemed fit.

Ok here we go:

> sqlplus / as sysdba
> create pfile='koen.ini' from spfile;

File created.

vi ./product/11.2.0/xe/dbs/koen.ini

remove the memory_target entry and replace it by


> sqlplus / as sysdba
> startup pfile=/u01/app/oracle/product/11.2.0/xe/dbs/koen.ini

ORACLE instance started.

Total System Global Area 601272320 bytes
Fixed Size 2228848 bytes
Variable Size 180358544 bytes
Database Buffers 415236096 bytes
Redo Buffers 3448832 bytes
Database mounted.
Database opened.

Et voila..

Hope this helps someone having the same issue..

zondag 24 januari 2010

dinsdag 5 januari 2010

Tomcat 6.0.20 finally supports proxied getRemoteAdr()

I've encountered this bug recently as I wanted to find relate sessions with their originator on a load-balanced tomcat in front of an nginx acting as a proxy. Until now I always had to put this in the lib folder of a tomcat installation. Now the guys from apache finally integrated it into their codebase (6.0.20) and it works right out of the box. Whoohoo!!

Happy new year !!

zondag 6 september 2009

We've got a little girl!!!

Elise was born last Tuesday, 1 September.


dinsdag 4 augustus 2009

Cometd vs BlazeDS : pushing messages to the client

In the constant quest of allowing web applications to use more functionality that was once found in fat clients (eg. VB, Delphi, C/C++). It has been historically difficult to push messages from the server to the client. Not only were there hoops to jump through on the network level, almost all (stateful) firewalls only allow sending data to a client that already established a connection (the famous syn bit). There is also the problem that most http servers (IIS and apache) don't like too many connections open for too long as they typically allocate memory to a connection. Furthermore on the client side, browsers didn't (until recently) have a standard way to handle server side events. And if things weren't bad enough there is still the minor issue with browser incompatibilities with IE as the negative role-model.

There are however a few alternatives to circumvent these limitations on which I'll highlight 2 (that I've used from personal experience).

The use case for this was in a domotics program (a pet project I work on). Here a java backend was connected via the serial port to the domotics bus. As soon as an event (being for example a light switched on) I wanted the status of the light updated in the front end. So the front-end contained a image representing the living room and smaller images the states of electric bulbs in that room. If one switched on the light then the same state would be represented on screen as soon as the event occurred with the least possible latency.

* Option 1 : Flex front-end and BlazeDS/GraniteDS backend through JMS

Although a Flex application on the front-end feels a bit like cheating, since the true source code is a bunch of actionscript files compiled into a SWF (aka flash file). It still gives the user a natural user experience in the browser. This flash file connects to the backend via amf over http. The AMF protocol is a proprietary binary protocol opened up recently by Adobe, which allows flash clients to connect to a backend. Until recently their backend of choice was either coldfusion or jrun, but since other web application servers (and tomcat/jetty in particular) were so widely used, Adobe open source'd BlazeDS as well. This combination has an option to use through JMS push server messages to the client.
BlazeDS and Flex were pretty simple to setup, but on the backend side, one required JMS which was typically not included for tomcat/jetty or one should switch over to a full blown J2EE server in which JMS was supported. Certainly with the new Web Profile of the the J(2)EE version the question pops up again which JMS system to use. Here again, tastes may differ, but I have a small tendency towards ActiveMQ as it's really fast and provides all kind of features like streaming messages.
Towards BlazeDs, there is however an alternative called graniteds which I favor as it contains less dependencies (like concurrent.jar, which is the predecessor of a backport of java.util.concurrent, old in other words) Their implementation is based on option 2 and is an implementation of the Bayeux spec as well.

* Option 2 : Html/javascript front-end and cometd backend

For me this was new (well I had heard about it, but I never came to test/use it). So there I was on (another) late nighter trying to find out more about HTML5 which seems to be a hot topic these days with stuff like the event sources and client-side caches. Problem was that there isn't that much material about the subject since the final spec is about to be released in 2022. So looking at event-sources it made me think back about cometd and I decided to give it a spin doing just a simple use-case like visualising the amount of free memory on the server. Although it didn't have any real immediate benifit, it was easy enough both backend and frontend to get me started to find out if it did fit my use-case
Boy, was I in for a surprise...

First of all, as with html documentation is a little scarse, although better than HTML5. The things I found however were still usable enough to mash up something useable together. So first step, backend (for me usually the easiest). Instead of starting my use case I decided to first try it with the proverbial hello world, to eventually step it up to my use case.

1. Import the required dependencies to use Cometd (or it's Bayeux implementation). These are small "cometd-java-server" is all you need to look for in the maven repository.
2. Implement a listener
3. Start sending messages out (by using the 'publish' method) As a merely sample project I outputted the memory available, the eventual use case would consume events from the serial port.

One note, I needed to import "org.eclipse.jetty.util.ajax.JSON.Literal" as it otherwise seems to escape quotes in the publish of a JSON message which renders the solution a bit less optimal :(.

On the front end, things couln't be simpler either.
1. Reference the cometd and it's implementation script (I chose to use jquery)

    <script type="text/javascript" src="${pageContext.request.contextPath}/org/cometd.js"></script>
<script type="text/javascript" src="${pageContext.request.contextPath}/jquery/jquery.cometd.js"></script>

2. Upon handshake, add a listener to the meta channel to listen to the channel on which you publish messages

         cometd.addListener('/meta/handshake', this, function(){
cometd.subscribe('/monitor/jvm', receive);
// Allow content to show

That's it, now you'll have updates on memory usage on the front-end. I added a small visualisation library to the mix so I could come to the following :