Date: Mon, 15 Dec 2014 10:37:01 -0500 From: Paul Pathiakis <pathiaki2@yahoo.com> To: Ronald Klop <ronald-lists@klop.ws>, Ed Maste <emaste@freebsd.org>, Paul Pathiakis <ppathiakis@atlantisservices.net>, Paul Pathiakis via freebsd-java <freebsd-java@freebsd.org> Subject: Re: Porting OpenNMS to FreeBSD 10.x with OpenJDK7 Message-ID: <548F001D.8020205@yahoo.com> In-Reply-To: <5480915F.6040204@yahoo.com> References: <546E2ED7.6010803@atlantisservices.net> <CAPyFy2CJonq6TCMQv36vZEg0Kup_J_vkaVcMmnJPeGi%2BuECgzw@mail.gmail.com> <547F3BD4.5010806@yahoo.com> <op.xqb6oqzqkndu52@ronaldradial.radialsg.local> <5480915F.6040204@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?548F001D.8020205>