April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9569) Class loading issue with the openjdk-orb on the JDK9

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-9569?page=com.atlassian.jira.plugin.... ] Tomasz Adamski commented on WFLY-9569: -------------------------------------- [~tomjenkinson] Looking. [~dmlloyd] This is the stacktrace: {code} WARNING: "IOP00110208: (BAD_PARAM) Could not load class InterpositionORBInitializerImpl" org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 208 completed: No at java.corba@9/com.sun.corba.se.impl.logging.ORBUtilSystemException.couldNotLoadClass(ORBUtilSystemException.java:1323) at java.corba@9/com.sun.corba.se.impl.logging.ORBUtilSystemException.couldNotLoadClass(ORBUtilSystemException.java:1342) at java.corba@9/com.sun.corba.se.spi.orb.OperationFactory$ClassAction.operate(OperationFactory.java:257) at java.corba@9/com.sun.corba.se.spi.orb.OperationFactory$ComposeAction.operate(OperationFactory.java:475) at java.corba@9/com.sun.corba.se.spi.orb.OperationFactory$MaskErrorAction.operate(OperationFactory.java:130) at java.corba@9/com.sun.corba.se.spi.orb.OperationFactory$ComposeAction.operate(OperationFactory.java:475) at java.corba@9/com.sun.corba.se.impl.orb.PrefixParserAction.apply(PrefixParserAction.java:82) at java.corba@9/com.sun.corba.se.spi.orb.PropertyParser.parse(PropertyParser.java:70) at java.corba@9/com.sun.corba.se.spi.orb.ParserImplBase.init(ParserImplBase.java:74) at java.corba(a)9/com.sun.corba.se.impl.orb.ORBDataParserImpl.<init>(ORBDataParserImpl.java:408) at java.corba@9/com.sun.corba.se.impl.orb.ORBImpl.postInit(ORBImpl.java:456) at java.corba@9/com.sun.corba.se.impl.orb.ORBImpl.set_parameters(ORBImpl.java:543) at java.corba@9/org.omg.CORBA.ORB.init(ORB.java:353) at OrbTest.main(OrbTest.java:6) Caused by: java.lang.ClassNotFoundException: InterpositionORBInitializerImpl at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496) at java.corba@9/com.sun.corba.se.impl.io.ValueUtility$1.loadClass(ValueUtility.java:104) at java.corba@9/com.sun.corba.se.spi.orb.OperationFactory$ClassAction.operate(OperationFactory.java:252) ... 11 more {code} In JDK < 9 the line: {code} return ValueUtility.class.getClassLoader().loadClass(className); {code} was meant to obtain the classloader of OpenJDK ORB module's classloader which has dependency on narayana and is able to load InterpositionORBInitializerImpl. Apparently in JDK9 the same line returns java.base/jdk.internal.loader.BuiltinClassLoader which is the cause of the error. > Class loading issue with the openjdk-orb on the JDK9 > ---------------------------------------------------- > > Key: WFLY-9569 > URL: https://issues.jboss.org/browse/WFLY-9569 > Project: WildFly > Issue Type: Bug > Components: IIOP > Reporter: Amos Feng > Assignee: Tomasz Adamski > Labels: jdk9 > > I had this issue when using the PortableInterceptor at the ORB ORBInitializer. > The root cause is https://github.com/jboss/openjdk-orb/blob/master/src/share/classes/com/su... > And the jigsaw classloader in the jdk9 might be investigated. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9569) Class loading issue with the openjdk-orb on the JDK9

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-9569?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-9569: ----------------------------------- Could you please post a stack trace and description of the problem? We should not play "hide the problem" with bug reports. Users are infinite, but maintainers are rare, so it is (IMO) courteous to include as much information as necessary to identify the issue without requiring maintainers to do additional research in order to have even a basic idea of what the issue is. > Class loading issue with the openjdk-orb on the JDK9 > ---------------------------------------------------- > > Key: WFLY-9569 > URL: https://issues.jboss.org/browse/WFLY-9569 > Project: WildFly > Issue Type: Bug > Components: IIOP > Reporter: Amos Feng > Assignee: Tomasz Adamski > Labels: jdk9 > > I had this issue when using the PortableInterceptor at the ORB ORBInitializer. > The root cause is https://github.com/jboss/openjdk-orb/blob/master/src/share/classes/com/su... > And the jigsaw classloader in the jdk9 might be investigated. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-124) Fix or replace the CNCF CI OpenShift Cluster

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-124?page=com.atlassian.jira.plugin.... ] Matt Mahoney updated SWSQE-124: ------------------------------- Team: Infrastructure > Fix or replace the CNCF CI OpenShift Cluster > -------------------------------------------- > > Key: SWSQE-124 > URL: https://issues.jboss.org/browse/SWSQE-124 > Project: Kiali QE > Issue Type: QE Task > Reporter: Kevin Earls > Assignee: Matt Mahoney > > As we've discussed in email, the CNCF CI OpenShift cluster is currently in a state where deleting some resources is impossible, which makes it impossible to run Jenkins tests. I first saw this when a test tried to delete ElasticSearch. Then after a cluster restart I saw the same problem with Cassandra. > We either need to figure out how to resolve the problem, or replace the cluster. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-124) Fix or replace the CNCF CI OpenShift Cluster

by Matt Mahoney (JIRA)

[ https://issues.jboss.org/browse/SWSQE-124?page=com.atlassian.jira.plugin.... ] Matt Mahoney updated SWSQE-124: ------------------------------- Sprint: Kiali QE Sprint 3 > Fix or replace the CNCF CI OpenShift Cluster > -------------------------------------------- > > Key: SWSQE-124 > URL: https://issues.jboss.org/browse/SWSQE-124 > Project: Kiali QE > Issue Type: QE Task > Reporter: Kevin Earls > Assignee: Matt Mahoney > > As we've discussed in email, the CNCF CI OpenShift cluster is currently in a state where deleting some resources is impossible, which makes it impossible to run Jenkins tests. I first saw this when a test tried to delete ElasticSearch. Then after a cluster restart I saw the same problem with Cassandra. > We either need to figure out how to resolve the problem, or replace the cluster. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10214) WFLYMSGAMQ0030: Failed to find SocketBinding for connector: http-connector

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-10214?page=com.atlassian.jira.plugin... ] Jeff Mesnil reassigned WFLY-10214: ---------------------------------- Assignee: Jeff Mesnil (was: Stuart Douglas) > WFLYMSGAMQ0030: Failed to find SocketBinding for connector: http-connector > -------------------------------------------------------------------------- > > Key: WFLY-10214 > URL: https://issues.jboss.org/browse/WFLY-10214 > Project: WildFly > Issue Type: Bug > Components: Application Client, JMS > Affects Versions: 12.0.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > When an appclient is configured with the messaging-activemq subsystem: > {code} > <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> > <server name="default" > > <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor" /> > <in-vm-connector name="in-vm" server-id="1"/> >  > > <connection-factory name="RemoteConnectionFactory" connectors="http-connector" entries="RemoteConnectionFactory java:/ConnectionFactory java:jboss/DefaultJMSConnectionFactory" consumer-window-size="0" thread-pool-max-size="10"/> > </server> > </subsystem> > {code} > There are intermittent errors during server start up: > {code} > \u001b[0m\u001b[31m09:27:42,858 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.messaging-activemq.default: org.jboss.msc.service.StartException in service jboss.messaging-activemq.default: WFLYMSGAMQ0033: Failed to start service > at org.wildfly.extension.messaging.activemq.ActiveMQServerService.start(ActiveMQServerService.java:359) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714) [jboss-msc-1.3.2.Final.jar:1.3.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693) [jboss-msc-1.3.2.Final.jar:1.3.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540) [jboss-msc-1.3.2.Final.jar:1.3.2.Final] > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.2.Final.jar:2.3.2.Final] > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.2.Final.jar:2.3.2.Final] > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.2.Final.jar:2.3.2.Final] > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364) [jboss-threads-2.3.2.Final.jar:2.3.2.Final] > at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_162] > Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYMSGAMQ0030: Failed to find SocketBinding for connector: http-connector > at org.wildfly.extension.messaging.activemq.ActiveMQServerService.start(ActiveMQServerService.java:216) > ... 8 more > {code} > If there are no acceptors, the connectors resource have only *optional* dependencies to the socket -binding (or outbound-socket-binding) service. > It happens that from time to time, the messaging-activemq subsystem performs its runtime before the socket binding service is started. > The dependency to the socket binding must be required for connectors resources (though for historical reasons, it can depend on either a socket-binding or an outbound-socket-binding) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10214) WFLYMSGAMQ0030: Failed to find SocketBinding for connector: http-connector

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-10214: ---------------------------------- Summary: WFLYMSGAMQ0030: Failed to find SocketBinding for connector: http-connector Key: WFLY-10214 URL: https://issues.jboss.org/browse/WFLY-10214 Project: WildFly Issue Type: Bug Components: Application Client, JMS Affects Versions: 12.0.0.Final Reporter: Jeff Mesnil Assignee: Stuart Douglas When an appclient is configured with the messaging-activemq subsystem: {code} <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"> <server name="default" > <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor" /> <in-vm-connector name="in-vm" server-id="1"/>  <connection-factory name="RemoteConnectionFactory" connectors="http-connector" entries="RemoteConnectionFactory java:/ConnectionFactory java:jboss/DefaultJMSConnectionFactory" consumer-window-size="0" thread-pool-max-size="10"/> </server> </subsystem> {code} There are intermittent errors during server start up: {code} \u001b[0m\u001b[31m09:27:42,858 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.messaging-activemq.default: org.jboss.msc.service.StartException in service jboss.messaging-activemq.default: WFLYMSGAMQ0033: Failed to start service at org.wildfly.extension.messaging.activemq.ActiveMQServerService.start(ActiveMQServerService.java:359) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714) [jboss-msc-1.3.2.Final.jar:1.3.2.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693) [jboss-msc-1.3.2.Final.jar:1.3.2.Final] at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540) [jboss-msc-1.3.2.Final.jar:1.3.2.Final] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.2.Final.jar:2.3.2.Final] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.2.Final.jar:2.3.2.Final] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.2.Final.jar:2.3.2.Final] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364) [jboss-threads-2.3.2.Final.jar:2.3.2.Final] at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_162] Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYMSGAMQ0030: Failed to find SocketBinding for connector: http-connector at org.wildfly.extension.messaging.activemq.ActiveMQServerService.start(ActiveMQServerService.java:216) ... 8 more {code} If there are no acceptors, the connectors resource have only *optional* dependencies to the socket -binding (or outbound-socket-binding) service. It happens that from time to time, the messaging-activemq subsystem performs its runtime before the socket binding service is started. The dependency to the socket binding must be required for connectors resources (though for historical reasons, it can depend on either a socket-binding or an outbound-socket-binding) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10213) JACC is broken after server reload

by Petr Jurak (JIRA)

Petr Jurak created WFLY-10213: --------------------------------- Summary: JACC is broken after server reload Key: WFLY-10213 URL: https://issues.jboss.org/browse/WFLY-10213 Project: WildFly Issue Type: Bug Components: Security Reporter: Petr Jurak Assignee: Stuart Douglas Fix For: 13.0.0.Beta1 It was discovered by https://github.com/wildfly/wildfly/pull/10829 that JACC has problems after server reload. org.jboss.security.jacc.JBossPolicyConfigurationFactory will always use the first 'org.jboss.security.jacc.DelegatingPolicy' that is set, while on reload org.jboss.as.security.service.SecurityBootstrapService will create and install a new policy, which means that after you execute a reload operation JACC is broken (provided the JBossPolicyConfigurationFactory was initialised before the reload). This will need to be fixed somehow, either by using the same DelegatingPolicy after reload, or by clearing the state in JBossPolicyConfigurationFactory. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-116) Reinstall openshift production cluster

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-116?page=com.atlassian.jira.plugin.... ] Filip Brychta commented on SWSQE-116: ------------------------------------- Ldap is working, updated https://mojo.redhat.com/docs/DOC-1167630 Other configuration will be done as part of other tasks > Reinstall openshift production cluster > -------------------------------------- > > Key: SWSQE-116 > URL: https://issues.jboss.org/browse/SWSQE-116 > Project: Kiali QE > Issue Type: Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Attachments: screenshot-1.png > > > Currently there are following problems with our OS cluster: > * docker on nodes is using loopback devices which is strongly discouraged for production use > * small partition for imagefs and nodefs which is causing issues "The node was low on resource: imagefs" > * different root passwords > We need to: > # investigate recommended partitioning for production OS clusters (also think about RAID versions available on each blade) > # reinstall RHELs with recommended partitions > # Configuring Docker Storage as described in https://docs.openshift.com/container-platform/3.9/install_config/install/... > # install OS 3.9 > # create mojo documentation -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-116) Reinstall openshift production cluster

by Filip Brychta (JIRA)

[ https://issues.jboss.org/browse/SWSQE-116?page=com.atlassian.jira.plugin.... ] Filip Brychta resolved SWSQE-116. --------------------------------- Resolution: Done > Reinstall openshift production cluster > -------------------------------------- > > Key: SWSQE-116 > URL: https://issues.jboss.org/browse/SWSQE-116 > Project: Kiali QE > Issue Type: Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Attachments: screenshot-1.png > > > Currently there are following problems with our OS cluster: > * docker on nodes is using loopback devices which is strongly discouraged for production use > * small partition for imagefs and nodefs which is causing issues "The node was low on resource: imagefs" > * different root passwords > We need to: > # investigate recommended partitioning for production OS clusters (also think about RAID versions available on each blade) > # reinstall RHELs with recommended partitions > # Configuring Docker Storage as described in https://docs.openshift.com/container-platform/3.9/install_config/install/... > # install OS 3.9 > # create mojo documentation -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10212) Deploying of jms bridge requires a lot of mandatory parameters

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-10212?page=com.atlassian.jira.plugin... ] Jeff Mesnil updated WFLY-10212: ------------------------------- Issue Type: Enhancement (was: Bug) > Deploying of jms bridge requires a lot of mandatory parameters > -------------------------------------------------------------- > > Key: WFLY-10212 > URL: https://issues.jboss.org/browse/WFLY-10212 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Affects Versions: 12.0.0.Final > Reporter: Erich Duda > Assignee: Jeff Mesnil > > As you can see in the listing \[1\], deploying of jms bridge requires a lot of mandatory parameters such as: {{max-batch-size}}, {{max-batch-time}}, {{max-retries}}, {{failure-retry-interval}}. > These parameters should not be mandatory and should use some reasonable defaults. > \[1\] > {code} > [standalone@localhost:9990 /] /subsystem=messaging-activemq/jms-bridge=mybridge:add( > ! max-batch-size* quality-of-service* source-credential-reference subscription-name target-destination* > add-messageID-in-header max-batch-time* selector source-destination* target-connection-factory* target-password > client-id max-retries* source-connection-factory* source-password target-context target-user > failure-retry-interval* module source-context source-user target-credential-reference > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2018