Voodoo Lab Pedal Power 2+ in Pedaltrain PT Pro einbauen - Auf die richtige Bohrlochgröße kommt es an

So, es ist vollbracht :-)
Ich habe meine zwei Voodoo Lab Pedal Power 2+ Netzteile unterhalb meines Pedaltrain PT Pro Boards angebracht.
Durch meinen Bodentreter-Wahn reichte ein Pedal Power Netzteil leider nicht mehr aus. Aber das schöne ist ja, dass das Pedaltrain Board großzügigen Platz bietet und man locker zwei oder sogar drei Voodoo Labs darunter schrauben kann.
Ich hatte allerdings mit ein paar Schwierigkeiten zu kämpfen.

1. Das Pedaltrain PT Pro Board besitzt nur einen Satz an Befestigungshalterungen und Schrauben für eben genau ein Voodoo Lab. Diese Befestigungshalterungen mal eben so zu besorgen ist nicht ganz einfach. Selbst mein "Local Dealer" um die Ecke hat mehrere Wochen gebraucht. Da ich solange nicht warten wollte hab ich mir dann welche bei einem ebay Händler aus den USA gekauft die preislich mit Versandkosten genauso teuer waren wie beim Kauf in einem Geschäft vor Ort. Die Lieferzeit betrug knapp 2 Wochen und war damit sogar noch etwas schneller als in meinem Gitarrenladen. Im Endeffekt scheint es aber ziemlich egal zu sein, ob man die Halterungen vor Ort in dem Laden seiner Wahl bestellt (vorrätig sind die meiner Erfahrung nach so gut wie nie) oder aus den USA importiert.
2. Das Befestigen der Halterungen ist prinzipiell ein Klacks. Es gibt im Internet massenweise Anleitungen dafür. Zum Beispiel diese hier mit einer guten Bebilderung (nicht für ein PT Pro, aber das Prinzip ist das gleiche) oder diese hier als Video bei youtube.
   Das einzige Problem das ich hatte war, dass alle Anleitungen auf englisch sind. Nicht, dass ich des englischen nicht mächtig wäre - ganz im Gegenteil - aber die Maßeinheiten und die Umrechungen vom englischen ins metrische System waren eine kleine Herausforderung. Warum das?
   In allen Anleitungen war die Rede davon, dass man die Löcher mit einem 1/8 drill bit Metallbohrer in das Pedaltrain bohren muss. Also ganz einfach dachte ich mir: Umrechnungstabelle von inch nach Millimetern im Netz suchen und einfach die passenden Bohrer besorgen. Ich hab dann diese Umrechnungstabelle gefunden und war etwas überrascht: Da stehen tatsächlich 2(!) metrische Bohrergrößen für den Wert 1/8 inch drin.
   3.1750 und 3.5000. Äh ja und nu?
   Tja, ich bin dann in den Baumarkt und hab nachgeschaut bzw. auch nochmal Google konsultiert: Es gibt entweder 3mm oder 3,5mm Bohrer. Ok, hab ich dann einen Set gekauft, der beide Bohrergrößen enthält. War auch nicht teuer und kann man sicherlich immer mal wieder gebrauchen.
3. Jetzt zum bohren: Welche Bohrergröße nimmt man denn dann? Erfahrung meinerseits: Nimm den 3,5mm Bohrer. Ich habe zuerst den 3mm Bohrer benutzt und da ist mir beim Eindrehen einer Schraube der Schraubenkopf tatsächlich abgebrochen. Das gebohrte Loch war zu schmal. Und nein - ich habe die Schraube nicht mit einem Akkubohrer eingeschraubt sondern ganz old-school per Hand.
   Mit den 3,5mm Löchern hat dann aber alles perfekt geklappt.

Ein Foto des fertigen Boards wird es sicherlich auch nochmal geben. Aber es sind noch nicht alle Effekte drauf und das Kabelwirrwarr muss erst noch "schön gemacht" werden.

Übrigens hab ich jetzt ein Rockcase 80x40 Board über. Sehr guter Zustand und wenig benutzt ...

Solution for "Sniffers with type [connector] and type [ejb] should not claim the archive at the same time"

In case you are using GlassFish it may happen you run into this error

"java.lang.IllegalArgumentException: Sniffers with type [connector] and type [ejb] should not claim the archive at the same time. Please check the packaging of your archive" 

In my case it happens when I deployed a web archive out of Eclipse directly into a running GlassFish instance on my machine using the GlassFish plugin. 

I tried a Google search for this error and found a blog posting by Adam Bien describing this error and a solution. Well, indeed my packaging was wrong. I accidentally bundled the artifact glassfish-embedded-all into my WAR archive and this was causing the trouble.

The solution is very simple: Either change the scope in your pom.xml to "provided" or - in case you don't need the dependency - remove it from the dependency section of your pom.

In my case it turns out that the dependency was not necessary anymore and I deleted it.

Stopping Tomcat with remote JMX enabled through script

Tomcat comes with handy start and stop scripts in the bin folder. Those scripts are working very well.
With this script it's pretty simple to start/stop Tomcat on linux systems.

But if you decide to add jmxremote properties to your start script using $JAVA_OPTS variable, stopping of Tomcat (and mostly any other AppServer started with these options) will not succeed.

There will be an error message stating that the address is already in use (BindException) and you have to kill the process manually.

The solution is very simple. Make sure the stop command does not contain the jmxremote properties definition. So you might declare a $JAVA_OPTS for the start command as usual:

 JAVA_OPTS="-Xmx256m -XX:MaxPermSize=128m 
-Dcom.sun.management.jmxremote.port=3336 
-Dcom.sun.management.jmxremote.ssl=false 
-Dcom.sun.management.jmxremote.authenticate=false 
-Djava.rmi.server.hostname=192.168.1.5"  

but for the stop command you must omit those jmx definitions and declare it for example like this:

 JAVA_OPTS_STOP="-Xmx256m -XX:MaxPermSize=128m"  

.
The stop command then forks a JVM with the $JAVA_OPTS_STOP definition NOT trying to open another listening socket on an already bound port.

Setting up an Apache cluster under RedHat Enterprise Linux

If it ever happens that you have to set up an Apache Linux cluster, I highly recommend the step-by-step manual from clusterlabs.org.
The docs are really easy to read and are very helpful.
I only have two negative points:

1. Sometimes the commands you have to enter into the console are not clearly separated from the parameters or text you have to pass. Example:
   

   cat <<-END >>/etc/corosync/service.d/pcmkservice {
           # Load the Pacemaker Cluster Resource Manager
           name: pacemaker
           ver:  1
   }
   END

   The file to create is called /etc/corosync/service.d/pcmk (NOT pcmkservice) and the content of the file starts with "service {
   # Load the Pacemaker ..."
   I assume this has something to do with the formatting of the docs.
2. The docs almost never tell you what to do in case things go wrong or you did a typo or your environment differs from the one used in the docs.
   In that case you have to use google and cross your fingers or use other resources like this one.

After all I only had to consult google once during the complete setup.

My failover tests succeeded after a few hours of setup including writing a howto for my specific setup.

Now the cluster works using corosync and pacemaker as services.