Porting OpenNMS to FreeBSD 10.x with OpenJDK7

Mon Dec 15 15:37:11 UTC 2014

Hi All!!!

OK.  Well, I've been working with the OpenNMS people for a couple of 
weeks and it looks like it's either FreeBSD or OpenJDK 1.7 that is the 
problem in their product working on FreeBSD.

It was tried in two configurations on 10.1.

Configuration:

OpenNMS 14.0.0.1 on both with FreeBSD 10.1

1) openjdk 1.7
2) linux-sun-jdk17

Ron Roskens over at the OpenNMS project ran through this to find out 
what was wrong:

I’ve been able to solve two of the unit test issues so far. Still running into the other unit test failures.

> On Dec 10, 2014, at 9:22 PM, Ronald Roskens<roskens at elfin.net>  wrote:
>
> Here are some of the ones I know about it erroring/failing, but don’t know why or how to fix them yet:
>
> org.opennms.core.test.db.MirgratorTest:
> testUpdate():
> org.opennms.core.schema.MigrationException: unable to migrate the database
>
> testMultipleChangelogs():
> PSQLException: ERROR: relation “databasechangelog” does not exist

NMS-7254: MigratorTest fails on two of the 3 tests.

The problem here is two fold.
First, the test environment as configured by the maven surefire plugin can be different, and results in different results. One run can use filesystem resources, subsequent runs use jar file resources.
Second, MigratorTest assume it will be passed jar file resources on the classpath.

> org.opennms.jicmp.jna.ByteBufferTest:
> testPassing():
> com.sun.jna.LastErrorException: errno was 47

NMS-7257: ByteBufferTest.testPassing() fails on FreeBSD 10.1
This one is due a difference between the sockaddr_in class on Linux vs FreeBSD. Having a BSD specific version of the ByteBufferTest class that uses bsd_sockaddr_in objects allows all tests to pass.

Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.243 sec <<< FAILURE! - in org.opennms.netmgt.provision.persist.RequisitionFileUtilsTest
testCreateTemporaryRequisition(org.opennms.netmgt.provision.persist.RequisitionFileUtilsTest)  Time elapsed: 0.013 sec  <<< FAILURE!
java.lang.AssertionError: expected:<2> but was:<1>
         at org.junit.Assert.fail(Assert.java:93)
         at org.junit.Assert.failNotEquals(Assert.java:647)
         at org.junit.Assert.assertEquals(Assert.java:128)
         at org.junit.Assert.assertEquals(Assert.java:472)
         at org.junit.Assert.assertEquals(Assert.java:456)
         at org.opennms.netmgt.provision.persist.RequisitionFileUtilsTest.testCreateTemporaryRequisition(RequisitionFileUtilsTest.java:74)

This failure seems to occur randomly. You can continue the test run after it fails, and this test will run successfully.

Then I run into some generate-features-xml errors which only occur on the first run.

The next test failure is:

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.345 sec <<< FAILURE! - in org.opennms.features.vaadin.nodemaps.internal.gwt.client.ui.controls.search.SearchStateTest
org.opennms.features.vaadin.nodemaps.internal.gwt.client.ui.controls.search.SearchStateTest  Time elapsed: 1.322 sec  <<< ERROR!
java.lang.VerifyError: Bad <init> method call from inside of a branch
Exception Details:
   Location:
     org/opennms/features/vaadin/nodemaps/internal/gwt/client/ui/controls/search/SearchStateTest$TestSchedulerImpl.<init>(Lorg/opennms/features/vaadin/nodemaps/internal/gwt/client/ui/controls/search/SearchStateTest$1;)V @34: invokespecial
   Reason:
     Error exists in the bytecode
   Bytecode:
     0000000: 2a4d 125b b800 1603 bd00 0d12 17b8 001b
     0000010: b800 213a 0419 04b2 0025 a500 0e2a 01c0
     0000020: 0027 b700 2aa7 0009 2cb7 005c 0157 b1
   Stackmap Table:
     full_frame(@40,{UninitializedThis,Object[#89],UninitializedThis,Top,Object[#13]},{})
     full_frame(@46,{Object[#2],Object[#89],Object[#2],Top,Object[#13]},{})

         at java.lang.Class.forName0(Native Method)
         at java.lang.Class.forName(Class.java:191)
         at javassist.runtime.Desc.getClassObject(Desc.java:43)
         at javassist.runtime.Desc.getClassType(Desc.java:152)
         at javassist.runtime.Desc.getType(Desc.java:122)
         at javassist.runtime.Desc.getType(Desc.java:78)
         at org.opennms.features.vaadin.nodemaps.internal.gwt.client.ui.controls.search.SearchStateTest.setUpClass(SearchStateTest.java:92)

Adding -noverify to the argLine configuration property for the maven surefire plugin gets us get beyond that error.

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To*unsubscribe*  or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss

Ron followed up with this e-mail after submitting all his patches to the 
code to allow for FreeBSD specifics:

> On Dec 13, 2014, at 10:27 PM, Ronald Roskens<roskens at elfin.net>  wrote:
>
> I was able to get the unit tests after that to run through to completion.
>
> I’ve checked my fixes for NMS-7254, NMS-7257, and NMS-7260 into a branch roskens/freebsd-build in the repository, and its just starting it run through the bamboo CI process.
>
> If its without any errors I’ll see about getting it merged into master & develop branches.
>
> I am cautiously optimistic that you could run a build of OpenNMS 14.0.2 on FreeBSD 10.1 with OpenJDK 1.7.0_71-b14. I think any further problems uncovered would likely be FreeBSD JVM specific issues with OpenJDK.
>
> Ron

My optimism has been greatly diminished because on running the build after about 10 minutes, the JVM crashed with a fatal error:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000803a4d4ae, pid=84602, tid=35353228288
#
# JRE version: OpenJDK Runtime Environment (7.0-b14) (build 1.7.0_71-b14)
# Java VM: OpenJDK 64-Bit Server VM (24.71-b01 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# j  java.net.SocketException.<init>(Ljava/lang/String;)V+0
#
# Core dump written. Default location: /cores/core or core.84602

When I tried to run OpenNMS with the linux-sun-jdk17 it runs, but I got this error in web.log when I tried to access the web interface.

2014-12-14 14:17:14,213 WARN  [Main] o.e.j.u.c.AbstractLifeCycle: FAILED org.eclipse.jetty.server.nio.SelectChannelConnector$ConnectorSelectorManager at 131fc7e: java.io.IOException: Function not implemented
java.io.IOException: Function not implemented
         at sun.nio.ch.EPollArrayWrapper.epollCreate(Native Method) ~[?:1.7.0_71]
         at sun.nio.ch.EPollArrayWrapper.<init>(EPollArrayWrapper.java:130) ~[?:1.7.0_71]
         at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:68) ~[?:1.7.0_71]
         at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:36) ~[?:1.7.0_71]
         at java.nio.channels.Selector.open(Selector.java:227) ~[?:1.7.0_71]
…

Which I take to mean that the FreeBSD Linux kernel emulator doesn’t implement the epoll interface.

Creating $OPENNMS_HOME/etc/opennms.conf with:
ADDITIONAL_MANAGER_OPTIONS="-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider"

Then its up and running.

Ron

Gentlemen of FreeBSD Java/OpenJDK....  It runs on the linux-sun-jdk17 
without issue once you put the two options into the file as described in 
the last 2-4 lines of the second letter.  Now that it's been narrowed 
down to being an OpenJDK compliance issue, could we please dig into it a 
bit?

I am going to run FreeBSD 10.1, OpenNMS 1.14.0.2 with OpenJDK-latest and 
see if the issue still exists.  I'm happy to assist but I'm not a java 
person and I would think that I have shown I am committed to getting 
this port done and to continue supporting the jicmp, jicmp6, jrrd, and 
the OpenNMS port going forward.  I need someone in the OpenJDK support 
group to assist in either finding where the problem is in OpenJDK or 
where OpenNMS makes an incorrect call in OpenJDK 1.7 on FreeBSD 10.1.  
(Although, I believe, Ron Roskens has pretty well dug in to find it's 
probably not OpenNMS.)

One last thing, the OpenNMS project tends to be Windows, MacOSX and LINUX

Check out what Ron had to say when first exposed to FreeBSD:

Thats pretty neat that FreeBSD have VM templates you can download and use as a base. Using that, I installed git, openjdk-7, jicmp, jicmp6 and postgresql94 packages.

I cloned the OpenNMS repo, checked out master, and then ran “./compile.pl && ./assemble.pl -Dopennms.home=/opt/opennms” which ran through to completion.

I wonder if using the linux jdk is whats causing it to attempt to run the NSIS part. You could try adding -Dos.name=FreeBSD to the build arguments to compile.pl and/or assemble.pl.

Ron

That's an open mind.  Can the FreeBSD community do any less than take 
the baton and run the next leg of this race?

Thank you for the effort in bringing this home!

P.

http://sourceforge.net/projects/opennms/?source=typ_redirect <---Source Code

Process:  download... unpack...

./compile.pl
./assemble.pl -Dopennms.home=/usr/local/opennms

When done, copy from initial directory/targets and grab the 
opennms-1.14.0.2.tar.gz and copy it to the home directory 
(/usr/local/opennms)

Unpack that in the directory.
You'll need a postgres instance to connect to.

Here to help with anything more.