IP Helper Library GetIfTable function failed (annoyingly often)

[eliasbalasis1]

Hello,

I have always been seeing "IP Helper Library GetIfTable function failed" while working with JBoss Server tools for Eclipse (since JBoss AS 7 age) but not as often as recently (to the degree that prevents me from working)

The problem disappears when I restart Eclipse but that's not desirable as it happens too often and unpredictably.

Also, contrary to some posts over the Internet about conflicting JRE installations, I now haven't any other Java installations on my machine plus I have always been using a custom JDK under ${ECLIPSE_HOME}/jre , I hope this helps

Please assist, this has become a major blocker, perhaps not only for me

Here is the exception stack trace I recovered from Eclipse error logs

java.lang.Error: IP Helper Library GetIfTable function failed

  at java.net.NetworkInterface.getByInetAddress0(Native Method)

  at java.net.NetworkInterface.getByInetAddress(NetworkInterface.java:325)

  at org.jboss.as.protocol.ProtocolConnectionUtils.isLocal(ProtocolConnectionUtils.java:201)

  at org.jboss.as.protocol.ProtocolConnectionUtils.getOptions(ProtocolConnectionUtils.java:133)

  at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:78)

  at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:114)

  at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257)

  at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71)

  at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:212)

  at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146)

  at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65)

  at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147)

  at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122)

  at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)

  at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)

  at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147)

  at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75)

  at org.jboss.ide.eclipse.as.internal.management.wildfly9.Wildfly9Manager.execute(Wildfly9Manager.java:350)

  at org.jboss.ide.eclipse.as.internal.management.wildfly9.Wildfly9Manager.getServerState(Wildfly9Manager.java:291)

  at org.jboss.ide.eclipse.as.internal.management.wildfly9.Wildfly9ManagerService.getServerState(Wildfly9ManagerService.java:142)

  at org.jboss.ide.eclipse.as.management.core.JBoss7ManagerServiceProxy.getServerState(JBoss7ManagerServiceProxy.java:71)

  at org.jboss.tools.as.core.server.controllable.subsystems.internal.ManagementPublishController.isRunning(ManagementPublishController.java:115)

  at org.jboss.tools.as.core.server.controllable.subsystems.internal.ManagementPublishController.canPublishInternal(ManagementPublishController.java:138)

  at org.jboss.tools.as.core.server.controllable.subsystems.internal.ManagementPublishController.publishStart(ManagementPublishController.java:154)

  at org.jboss.tools.as.core.server.controllable.internal.DeployableServerBehavior.publishStart(DeployableServerBehavior.java:109)

  at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:942)

  at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:774)

  at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:3172)

  at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:345)

  at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

I am using

Windows 7 64-bit

Eclipse Mars 4.5.1

JDK 1.8.0_60

Wildfly 9.0.1

[eliasbalasis1]

I can't explain it, but setting all bindings on configuration file (standalone-full.xml) to 0.0.0.0 seems to have an effect as I haven't seen the problem again since I reported it

Any ideas?

[maxandersen]

I've never seen this error before.

looks like an Windows + JVM version + permission specific issue when googling about it.

good you found a way to see it less - let us know if you find a way to reliably reproduce it.

[eliasbalasis1]

I feel it is Windows OS related, I will try some different combinations to isolate it and hopefully reproduce it reliably.

No JVM version permission case here as I have un-installed all my JVMs and using (as always) a JVM copy under Eclipse.

I have observed Eclipse accessing both the JVM copy and the system one (for no obvious reason) but problem was still reproducible with just the JVM copy.

I just can't explain it, I will try to reliably reproduce, hopefully.

[eliasbalasis1]

I think I found something,

It looks like when the JAVA_HOME environment variable and JRE with Eclipse is starting are not an exact match, there is a high risk or reproducing the feature.

I suspect that somehow the JBoss Eclipse plugins use the external JRE in ${JAVA_HOME} instead of the JRE with which Eclipse was started. I have proof of that, I have seen it happening in the past.

It happened again when I thought it wouldn't and as soon as I pointed ${JAVA_HOME} to same JRE as Eclipse the problem disappeared.

This matches with resolution in a couple of posts I found over the Internet about multi-JRE conflicts and un-installing all JREs etc.

I can only suspect that when different JREs are involved within the scope of the JBoss Tools plugins something is happening. Use of JAVA_HOME is suspicious in any case.

I hope this helps.

[maxandersen]

Not following why you think use of JAVA_HOME is suspicious ?

In any case,  i'm pretty sure this code just uses the JDK eclipse is running with - we can't mid-thread change the vm used. We are running inside Eclipse, not the other way around.

You can always check in Eclipse About dialog which JVM is actually being used.

[eliasbalasis1]

As soon as I pointed JAVA_HOME to Eclipse JRE the problem disappeared.

It is implied that the affected component is mainly JBoss Tools.

Since this is the only change performed between the problem and no-problem states I can only assume that somehow JBoss Tools is not using the Eclipse JRE but JAVA_HOME instead.

Moreover, I have seen Eclipse making use of JAVA_HOME instead of its own JRE in the past as part of attempt to uninstall system JDK (pointed to by JAVA_HOME) and Eclipse.exe was the blocker.

This confirms that Eclipse is indeed using JAVA_HOME instead of its own JRE.

It can only be implied that JBoss Tools is not using the Eclipse JRE but JAVA_HOME instead.

In other words, I am changing JAVA_HOME and Jboss Tools behaviour is fixed, it can only mean that JBoss Tools is using JAVA_HOME instead of Eclipse JRE

I hope this explains things better.

[eliasbalasis1]

It has been a long time since I last experienced this, but, I am using later version of JBoss Tools (for Eclipse Neon)

I consider this resolved in later versions of JBoss Tools