Ich installiere gerade eine Java Anwendung in einem Windows 2008 Server.
Dabei verwende ich ein Windows XP als Host, Sun's VirtualBox als VMM und das Windows 2008 Core Edition liegt als dynamisch wachsende virtuelle Festplatte im VHD Format vor.
Jetzt trat das Problem auf, dass der Host nicht mehr genug Speicherplatz für das wachsende Image hatte. Dies wurde dem Java Programm sauber als IOException gemeldet, aber als Reason wird (verständlicherweise) kein "file system full" oder "no space on device" gegeben, sondern die Meldung:
"The drive cannot find the sector requested"
Dies ist verständlich, wenn man sich vor Augen hält dass der IDE Treiber den Fehlerzustand an das NTFS des Guests melden muss. Ein "Kann den Sektor nicht belegen" ist so ziemlich der passendste Fehler der man sich in der Schicht denken kann.
Dieser Bug ist übrigens extrem kritisch. Im Gegensatz zur Platznot im Filesystem - von der sich das Filesystem wieder erholen kann - sind Allocation Fehler von beliebigen Sektoren deutlich kritischer, insbesondere wenn das bei Filesystem Meta Blöcken passiert statt bei Datenblöcken. Schnell kann das Filesystem dann aussteigen. Dies wiederum ist der Tot des Servers, wenn es sich dabei um System-Partition oder Swap-Partition handelt. Diese Laufwerksarten sollte man also in einer virtualisierten Umgebung niemals auf eine virtuelle Disk mit uncommited Speicher legen. Sicher kann man damit etwas Platz sparen und wenn man das ganze überwacht passiert es selten. Aber wenn es passiert, so kann man den Guest erst mal rebooten (worst case).
Dabei verwende ich ein Windows XP als Host, Sun's VirtualBox als VMM und das Windows 2008 Core Edition liegt als dynamisch wachsende virtuelle Festplatte im VHD Format vor.
Jetzt trat das Problem auf, dass der Host nicht mehr genug Speicherplatz für das wachsende Image hatte. Dies wurde dem Java Programm sauber als IOException gemeldet, aber als Reason wird (verständlicherweise) kein "file system full" oder "no space on device" gegeben, sondern die Meldung:
"The drive cannot find the sector requested"
Dies ist verständlich, wenn man sich vor Augen hält dass der IDE Treiber den Fehlerzustand an das NTFS des Guests melden muss. Ein "Kann den Sektor nicht belegen" ist so ziemlich der passendste Fehler der man sich in der Schicht denken kann.
Dieser Bug ist übrigens extrem kritisch. Im Gegensatz zur Platznot im Filesystem - von der sich das Filesystem wieder erholen kann - sind Allocation Fehler von beliebigen Sektoren deutlich kritischer, insbesondere wenn das bei Filesystem Meta Blöcken passiert statt bei Datenblöcken. Schnell kann das Filesystem dann aussteigen. Dies wiederum ist der Tot des Servers, wenn es sich dabei um System-Partition oder Swap-Partition handelt. Diese Laufwerksarten sollte man also in einer virtualisierten Umgebung niemals auf eine virtuelle Disk mit uncommited Speicher legen. Sicher kann man damit etwas Platz sparen und wenn man das ganze überwacht passiert es selten. Aber wenn es passiert, so kann man den Guest erst mal rebooten (worst case).
Geschrieben von Bernd Eckenfels
in Hardware, Infrastruktur, Java Programming
| Kommentare (0)
| Trackbacks (0)
Martin Fowler schreibt gerade an einem Buch über Domain Spezifische Sprachen (DSL), und in diesem Zusammenhang produziert er interessante Blog Artikel. Ich möchte hier auf einen Artikel von Ihm hinweisen, mit dem Titel "Parser Fear". Amüsantes Zitat am Rande:
Ist sicherlich interessant zu sehen was Fowler zusammenbrauen wird. Eine Sache dich ich übrigens interessant finde ist, dass er sich um das Thema DSL Workbenches im Buch "drückt" und selbst ANTLR als Basis verwendet. Immerhin gibt es doch einige sehr leistungsfähige Projekte zum Beispiel Eclipse Modelling oder Visual Studio DSL Tools.
So why is there an unreasonable fear of writing parsers for DSLs? I think it boils down to two main reasons.
- You didn't do the compiler class at university and therefore think parsers are scary.
- You did do the compiler class at university and are therefore convinced that parsers are scary.
The first is easy to understand, people are naturally nervous of things they don't know about. The second reason is the one that's interesting. What this boils down to is how people come across parsing in universities. Parsing is usually only taught in a compiler class, where the context is to parse a full general purpose language. Parsing a general purpose language is much harder than parsing a Domain Specific Language, if nothing else because the grammar will be much bigger and often contain nasty wrinkles which you can avoid with a DSL.
Ist sicherlich interessant zu sehen was Fowler zusammenbrauen wird. Eine Sache dich ich übrigens interessant finde ist, dass er sich um das Thema DSL Workbenches im Buch "drückt" und selbst ANTLR als Basis verwendet. Immerhin gibt es doch einige sehr leistungsfähige Projekte zum Beispiel Eclipse Modelling oder Visual Studio DSL Tools.
Geschrieben von Bernd Eckenfels
in Enterprise IT, ROTFLBTC, SW Entwicklung
| Kommentare (2)
| Trackbacks (0)
Virtuelle Realitäten wie Second Life werden ja schon für Geschäftsmeetings (z.B. Vorträge) genutzt. Sun arbeitet mit Project Wonderland an einer Plattform, die speziell für die Zusammenarbeit in Teams ausgelegt ist.
Hier ein nettes Demo Movie der Telefon Integration in Wonderland. Und eine ältere Demo des "virtuellen" Sun Gebäudes MPK20.
Das ganze ist verspielt, und es muss sich erst zeigen ob Konferenzteilnehmer dadurch wirklich Produktivität gewinnen und nicht verlieren, aber unterhaltsam ist es allemal.
Hier ein nettes Demo Movie der Telefon Integration in Wonderland. Und eine ältere Demo des "virtuellen" Sun Gebäudes MPK20.
Das ganze ist verspielt, und es muss sich erst zeigen ob Konferenzteilnehmer dadurch wirklich Produktivität gewinnen und nicht verlieren, aber unterhaltsam ist es allemal.
Ich habe immer ein sehr mulmiges Gefühl wenn ich Übersetzungen aus unserem Ost-Europäischen oder asiatischen Office bekomme - man kann diese so gar nicht kontrollieren. Dieses Problem haben wohl auch Chinesische Shop Besitzer, die sich ein englischsprachiges Ladenschild zulegen wollen. Allerdings ist es fraglich ob man dieser Art von automatisierter Übersetzung sehr weit trauen sollte:

Via Mela via AdFreak via Dear Jane Sample from DrNo.de

Via Mela via AdFreak via Dear Jane Sample from DrNo.de
Heute finden an der Uni-Karlsruhe gleich zwei interessante Termine statt. Die Java User Group Karlsruhe musste deswegen in den Raum -102UG in der Informatik Fakultät ausweichen, dort gibt es um 19:15Uhr (-21:15) einen Vortrag von Dr. Patrick Schemitz (Netpioneer GmbH) zum Thema Grundladen [Web] Security Auditing.
In -101UG spricht Dr. York Sure von SAP Research im Rahmen der GI/ACM Regionalgruppe Karlsruhe über Internet of Services. Dabei geht es um den Einsatz von Semantischen Technologien bei der Vermarktung von Internet Services.
Beide Termine finden sich auf dem IT-Kalender des Stadtblog KA. Dort findet sich auch eine Ankündigung für Morgen: Gründung des "Verein der Karlsruher Software-Ingenieure" um 16:00-18:00 am FZI. Näheres dazu in der Presseerklärung von FZI, KIT, adrena objects, 1&1, SAP und HsK.
Ich werde wohl bei der JUG-KA vorbeischauen heute Abend und mir Morgen die Info Veranstaltung ansehen.
In -101UG spricht Dr. York Sure von SAP Research im Rahmen der GI/ACM Regionalgruppe Karlsruhe über Internet of Services. Dabei geht es um den Einsatz von Semantischen Technologien bei der Vermarktung von Internet Services.
Beide Termine finden sich auf dem IT-Kalender des Stadtblog KA. Dort findet sich auch eine Ankündigung für Morgen: Gründung des "Verein der Karlsruher Software-Ingenieure" um 16:00-18:00 am FZI. Näheres dazu in der Presseerklärung von FZI, KIT, adrena objects, 1&1, SAP und HsK.
Ich werde wohl bei der JUG-KA vorbeischauen heute Abend und mir Morgen die Info Veranstaltung ansehen.
Geschrieben von Bernd Eckenfels
in Java Programming, Marketing, SOA, Technik
| Kommentare (2)
| Trackbacks (0)
Dieses mal nur schnell einen Pointer zu einer Artikelserie von Jeroen Borgers auf InfoQ. Ich weise ausdrücklich darauf hin dass der erste Teil des Artikels nicht ohne den zweiten Teil genossen werden sollte.
Zusätzlich möchte ich noch auf den Micro Benchmark Runner von Brent Boyer verweisen. Dieser spart ein wenig die manuelle Korrektur und Anpassung der Warmup-Phasen und liefert aussagekräftige statistische Auswertungen. Die developerWorks Artikelserie geht auf diese Verfahren auch noch etwas genauer ein:
Zusätzlich möchte ich noch auf den Micro Benchmark Runner von Brent Boyer verweisen. Dieser spart ein wenig die manuelle Korrektur und Anpassung der Warmup-Phasen und liefert aussagekräftige statistische Auswertungen. Die developerWorks Artikelserie geht auf diese Verfahren auch noch etwas genauer ein:
In einem Report (PDF) des U.S. DoD findet man folgende - doch recht amüsante - Anmerkung:
Es ist interessant zu sehen, dass einer der Haupt-Initiatoren der Common Criteria nun erkennt, dass diese nicht sehr nützlich ist - und was noch viel interessanter ist - nicht so einfach geändert werden kann, da diese nun im Standardisierung-Morast festsitzt.
Auf den Report hat übrigen's Oracle's CSO Mary Ann Davidson hingewiesen.
The primary process relied upon by the DoD for evaluation of the assurance of
commercial products today is the Common Criteria (CC) evaluation process. The
task force believes that Common Criteria is presently inadequate to raise
sufficiently the trustworthiness of software products for the DoD. This is
particularly true at Evaluation Assurance Level-4 (EAL4) and below, where
penetration testing is not performed. Nonetheless, Common Criteria evaluation is
an international program, well established, and not easy to change.
Es ist interessant zu sehen, dass einer der Haupt-Initiatoren der Common Criteria nun erkennt, dass diese nicht sehr nützlich ist - und was noch viel interessanter ist - nicht so einfach geändert werden kann, da diese nun im Standardisierung-Morast festsitzt.
Auf den Report hat übrigen's Oracle's CSO Mary Ann Davidson hingewiesen.
Das Thema der null Referenzen in Java, insbesondere als Rückgabewert von Methoden ist umstritten. Generell führt es zu einer erhöhten Gefahr von (aussagelosen) NullPointerExceptions.
An manchen stellen kann man diese einfach vermeiden: finder die eine Liste von Objekten zurückliefern sollten eine leere Ergebnismenge (die ohne Fehler zustande gekommen ist) nicht mit einem null; Rückgabewert signalisieren, sondern mit einer leeren Collection: "return List.EMPTY_LIST;".
An anderen Stellen ist die Vermeidung von null nicht immer unumstritten. Auf die Diskussion will ich mich hier jetzt garnicht einlassen. Deswegen habe ich hier eine einfache Policy - falls null Rückgabe Werte doch zulässig sein sollten:
Wenn schon null als Rückgabe Wert einer Methode, so darf dies nur passieren wenn:
Ein Negativbeispiel ist dies hier (der Code mit der Entscheidungsfindung ist hier deutlich übersichtlicher als bei größeren Methoden mit state variablen in der Praxis:
Mit einem expliziten return wird dies klarer, entweder (die von mir oftmals bevorzugte Early-Out Variante):
Oder eine if/else Cascade:
Wichtig ist dabei immer, dass im Code klar wird, was die Intention ist - also: soll null wirklich zurückgegeben werden oder wurde nur eine Fallunterscheidung vergessen. Wenn man sich dazu überwindet "return null;" zu schreiben, so ist es zugegebenermaßen manchmal etwas langatmiger, aber dafür eindeutig.
Eine Code Policy wie "jede Methode darf nur einen return punkt haben" ist übrigens nicht nur weil es dieses Idiom verbietet unsinnig. Das führt nur zu extremen Verschachtelungen. Dank Java finally gibt es dazu auch sehr selten Grund.
Übrigens versuche ich auch die returns innerhalb eines entsprechenden try/finally Blocks zu haben und vermeide "Alibi" returns am ende der Methode - die beschwichtigen nur erwünschte Warnings.
An manchen stellen kann man diese einfach vermeiden: finder die eine Liste von Objekten zurückliefern sollten eine leere Ergebnismenge (die ohne Fehler zustande gekommen ist) nicht mit einem null; Rückgabewert signalisieren, sondern mit einer leeren Collection: "return List.EMPTY_LIST;".
An anderen Stellen ist die Vermeidung von null nicht immer unumstritten. Auf die Diskussion will ich mich hier jetzt garnicht einlassen. Deswegen habe ich hier eine einfache Policy - falls null Rückgabe Werte doch zulässig sein sollten:
Wenn schon null als Rückgabe Wert einer Methode, so darf dies nur passieren wenn:
- im Javadoc erwähnt wird "@returns the Object requested or null"
- der null Wert im Code durch ein explizites "return null;" angegeben wird.
Ein Negativbeispiel ist dies hier (der Code mit der Entscheidungsfindung ist hier deutlich übersichtlicher als bei größeren Methoden mit state variablen in der Praxis:
public IThing getCarOrBike(int distance, Person p) {
IThing ret = null;
if (distance > 1000) {
ret = new Car();
ret.add(p);
}
if (distance > 100) {
ret = new Bike();
ret.add(p);
}
return ret; // BAD
}Mit einem expliziten return wird dies klarer, entweder (die von mir oftmals bevorzugte Early-Out Variante):
public IThing getCarOrBike(int distance, Person p) {
if (distance < 0 || p == null)
throw new IllegalArgumentException("You must specify a person and positive distance");
if (distance <= 100)
return null; // pedestrian
IThing ret;
if (distance > 1000) {
ret = new Car();
} else {
ret = new Bike();
}
ret.add(p);
return ret;
}Oder eine if/else Cascade:
/**
* Return Transportation for given distance.
* <P>
* This will return instances of Car or Bike. If the distance
* is short enough, null will be returned.
*
* @return null or new instance of Car or Bike with person added
*/
public IThing getCarOrBike(int distance, Person p) {
IThing ret = null;
if (distance > 1000) {
ret = new Car();
} else if (distance > 100) {
ret = new Bike();
} else {
return null; // pedestrian
}
ret.add(p);
return ret;
}Wichtig ist dabei immer, dass im Code klar wird, was die Intention ist - also: soll null wirklich zurückgegeben werden oder wurde nur eine Fallunterscheidung vergessen. Wenn man sich dazu überwindet "return null;" zu schreiben, so ist es zugegebenermaßen manchmal etwas langatmiger, aber dafür eindeutig.
Eine Code Policy wie "jede Methode darf nur einen return punkt haben" ist übrigens nicht nur weil es dieses Idiom verbietet unsinnig. Das führt nur zu extremen Verschachtelungen. Dank Java finally gibt es dazu auch sehr selten Grund.
Übrigens versuche ich auch die returns innerhalb eines entsprechenden try/finally Blocks zu haben und vermeide "Alibi" returns am ende der Methode - die beschwichtigen nur erwünschte Warnings.
Bilder des ersten Tages der Open Expo in Karlsruhe habe ich auf meinem Ipernity account abgelegt.
Es war nicht allzu voll, die beteiligten Open Source Projekt-Aussteller haben sich aber sehr gut versorgt gefühlt. Mir persönlich hat eine Moderation und Betreuung der Redner gefehlt. Bis auf die Keynote von Mike Milinkovich (Executive Director Eclipse Foundation) waren die Vorträge teils Produkt/Marketing related und teils Vorträge von Praktikern. Witzigerweise haben die meisten davon auf Ihre High-Profile Kollegen die den gleichen Vortrag auf dem Linuxtag halten werden verwiesen.
Heute ist der erste Tag an dem die Veranstaltung parallel zur Webinale stattfindet, bin mal gespannt wie die Besuchsberichte so ausfallen. Ich werde heute nicht dort sein, dafür aber Abends als Gast auf dem Geek Girl Dinner (Fotos bei Mela).
Es war nicht allzu voll, die beteiligten Open Source Projekt-Aussteller haben sich aber sehr gut versorgt gefühlt. Mir persönlich hat eine Moderation und Betreuung der Redner gefehlt. Bis auf die Keynote von Mike Milinkovich (Executive Director Eclipse Foundation) waren die Vorträge teils Produkt/Marketing related und teils Vorträge von Praktikern. Witzigerweise haben die meisten davon auf Ihre High-Profile Kollegen die den gleichen Vortrag auf dem Linuxtag halten werden verwiesen.
Heute ist der erste Tag an dem die Veranstaltung parallel zur Webinale stattfindet, bin mal gespannt wie die Besuchsberichte so ausfallen. Ich werde heute nicht dort sein, dafür aber Abends als Gast auf dem Geek Girl Dinner (Fotos bei Mela).
Geschrieben von Bernd Eckenfels
in Java Programming, Karlsruhe, Marketing
| Kommentare (0)
| Trackbacks (0)
Da ich davon beim abendlichen Beercall erzählt bekam gehe ich davon aus, dass es schon alte News ist und sage dazu nichts weiter... naja außer vielleicht:
2ecki@calista:~> dpkg -l openssl ||/ Name Version Description +++-===================-===================-====================================================== ii openssl 0.9.7e-3sarge5 Secure Socket Layer (SSL) binary and related cryptogra
Geschrieben von Bernd Eckenfels
in Infrastruktur, Sicherheit, SW Entwicklung
| Kommentare (0)
| Trackbacks (0)
« vorherige Seite
(Seite 3 von 9, insgesamt 89 Einträge)
nächste Seite »
Layout by Ricky Wilson | Serendipity Template by Carl Galloway | Login
Impressum
Bernd Eckenfels
Mörscher Str. 8
76185 Karlsruhe
bernd-2012@eckenfels.net
Read More

Kommentare