What to do if JBoss EAP6 fails to discover other cluster members with the following error from JGroups?
[org.jgroups.protocols.MPING] failed sending discovery request: java.io.IOException: Invalid argument at java.net.PlainDatagramSocketImpl.send(Native Method) at java.net.DatagramSocket.send(DatagramSocket.java:693) at org.jgroups.protocols.MPING.sendMcastDiscoveryRequest(MPING.java:300)
In my case the solution was simple. Add
-Djava.net.preferIPv4Stack=true to jbossctl.sh. Apparently the multicast code doesn’t work with IPv6 on my Linux version.
People often ask me if we should upgrade to the latest Java version and I always answer the same thing. Of course we should, what could be wrong about better performance and the latest security updates? I always amend something about trying it in a test environment first, though. Over the years I have seldom seen any problems with a Java SE update, the platform is remarkably backwards compatible. But then magic entered the stage.
The magic in this case is the build time byte code enhancement performed by OpenJPA. Apparently the byte code verifier was changed a bit in Java SE 7, so the classes are no longer valid. Oracle’s JVM complains. IBM’s Java 7 implementation crashes spectacularly. With Java 6 it just works.
OpenJPA has always been my least favourite JPA implementation and this did nothing to change that. Oh, they have fixed the byte code enhancer in newer versions (but if you are stuck with an old application server that might not help), but a similar problem exists for Java SE 8 and who wants to bet on everything playing out with Java 9 and 10? Not me.
It also says something about IBM’s JDK. It really shouldn’t crash on an invalid class, simply reject it and move on.
Nevertheless, my recommendation is still to use the latest Java version, but again – test it first and if you are using OpenJPA and/or anything but Oracle’s mainstream JVM, test it well!
WebSphere 8.5.5 normally uses LTPA tokens for authentication and session cookies for tracking HTTP sessions. The two are not connected and they interact in a sometimes very frustrating way. The HTTP session expires when the user has been inactive (i.e. no requests have been received by the server) for a given time. The LTPA token on the other hand has a fixed expiration time regardless of user activity. This means that a user can be logged out while active and while still having a session. Furthermore it is tricky to handle this as any attempt to access the session for a logged out user fails with an UnauthorizedSessionRequestException, complaining that an anonymous user has attempted to access a session owned by someone else. What to do?
There is a configuration option described here and here that makes the session manager invalidate the session and return null instead. This works well as that is what web applications normally do when a user has been logged out, so it plays nicely with other security frameworks.
To enable the option pick Servers-Server Types-WebSphere application servers-servier name-Session management, find Additional Properties and select Custom Properties, then set InvalidateOnUnauthorizedSessionRequestException=true. Save the changes and restart the server. The UnauthorizedSessionRequestException is history!
We recently had a break-in and found out about it when we were far from home. I worried about many things, among them the unencrypted files on my home NAS. Not that I have any state secrets buried, but the thought of having private e-mails, photos and so on in the hands of criminals just felt wrong. Fortunately the thieves left my computers, so I decided to do something about it.
I have an old NAS with FreeBSD 0.7.2 (no longer available) running FreeBSD 7. It does support encryption, albeit a bit manually. First I had to create a geli encryption key on the USB boot device:
umount /cf mount -o rw /dev/da0a /cf mkdir /cf/boot/keys dd if=/dev/random of=/cf/boot/keys/nas.key bs=128k count=1
Next I destroyed the partition on the first disk to go and configured it for encryption with geli:
dd if=/dev/zero of=/dev/ad10 bs=512 count=10 geli init -b -K /cf/boot/keys/nas.key -s 4096 -l 256 /dev/ad10 geli attach -k /cf/boot/keys/nas.key /dev/ad10
Repeat with other drives (ad8 in this case) and create a mirror:
zpool create -m none nas-pool1 mirror /dev/ad10.eli /dev/ad8.eli
/cf/boot/loader.conf to enter the passphrases at boot time:
geli_ad8_keyfile0_load="YES" geli_ad8_keyfile0_type="ad8:geli_keyfile0" geli_ad8_keyfile0_name="/boot/keys/nas.key" geli_ad10_keyfile0_load="YES" geli_ad10_keyfile0_type="ad10:geli_keyfile0" geli_ad10_keyfile0_name="/boot/keys/nas.key"
Reboot and make sure it works, then add additional drives and resilver. Peace of mind restored!