December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2090) JGRP000027: failed passing message up

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2090?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2090: -------------------------------- Right, this is what I usually recommend. Another option is to reduce the ip_ttl such that packets netween networks are dropped, or use VLANs altogether. > JGRP000027: failed passing message up > ------------------------------------- > > Key: JGRP-2090 > URL: https://issues.jboss.org/browse/JGRP-2090 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.10 > Reporter: Will Wright > Assignee: Bela Ban > Fix For: 3.6.11 > > > The JGroups library is generating NullPointerExceptions when attempting to process incoming messages. From what I can tell this is due to it looking for an incorrect message header. > The TP object has a protocol id of 75 despite being a TUNNEL which ought to have an id of 24. The id is being correctly assigned to 24 at the Protocol.id member variable declaration, but is then subsequently changed to 75 by the TP.init method. This seems to have been caused by commit [6bc167f7e0181af32e1930935d8cf0efdc1e82f0|https://github.com/belaban/JGrou...] which has the message "Added TP to jg-protocols.xml". If I backout this change to the TP.init method so as to not update the id then my application receives the incoming messages fine. > java.lang.NullPointerException: null > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2090) JGRP000027: failed passing message up

by Paul Illingworth (JIRA)

[ https://issues.jboss.org/browse/JGRP-2090?page=com.atlassian.jira.plugin.... ] Paul Illingworth commented on JGRP-2090: ---------------------------------------- I am seeing the same issue. For me the problem is that I am on a development network where there are several JGroups domains/clusters active all using the same UDP muticast addresses and ports but are differentiated by domain/cluster name. The other domains on the network are using JGroups 3.6.3 whilst I am using 3.6.11 - this means I get the NPE. I can avoid the problem by changing my UDP multicast address or port to "physically" separate the domains/cluster instead of just relying on the domain name. > JGRP000027: failed passing message up > ------------------------------------- > > Key: JGRP-2090 > URL: https://issues.jboss.org/browse/JGRP-2090 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.10 > Reporter: Will Wright > Assignee: Bela Ban > Fix For: 3.6.11 > > > The JGroups library is generating NullPointerExceptions when attempting to process incoming messages. From what I can tell this is due to it looking for an incorrect message header. > The TP object has a protocol id of 75 despite being a TUNNEL which ought to have an id of 24. The id is being correctly assigned to 24 at the Protocol.id member variable declaration, but is then subsequently changed to 75 by the TP.init method. This seems to have been caused by commit [6bc167f7e0181af32e1930935d8cf0efdc1e82f0|https://github.com/belaban/JGrou...] which has the message "Added TP to jg-protocols.xml". If I backout this change to the TP.init method so as to not update the id then my application receives the incoming messages fine. > java.lang.NullPointerException: null > at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1872) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7721) Support module slots for foreign JMS bridges

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-7721?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-7721: ---------------------------------------- There was a fairly general effort recently to make name:slot work for all such attributes. It's even possible this is already done in master. > Support module slots for foreign JMS bridges > -------------------------------------------- > > Key: WFLY-7721 > URL: https://issues.jboss.org/browse/WFLY-7721 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Robert Lee > Assignee: Jeff Mesnil > Labels: artemis, bridge, jmsbridge, modules, slot > > It would be nice to specify the slot, along with the module, for a JMS bridge. > *Use case*: > When setting up a JMS bridge with a foreign JMS system, the "module" option can be used (as a CLI parameter or an XML attribute) to specify the library code for the foreign JMS system, as a JBoss Module. > We have a number of different versions of a legacy messaging API. We have previously set up modules for direct use within our deployed application code, using different slots for different versions of the foreign JMS system. > We are now trying to migrate away from our different messaging systems towards Wildfly/Artemis, and have tried to set up JMS bridges to connect with the different systems. > Unfortunately, it is not possible to use any module slot other than "main" with a JMS bridge. There is no "slot" attribute in the XML, and if we try to use "modulename:slot" notation, then we get an error saying that the module could not be loaded. Turning up debugging shows it is looking for "modulename\:slot:main". > This seems like an omission, and is causing us to have to rework code to avoid the use of slots for different versions of the same library, which seems like a step backwards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2067) Upgrade to JBoss Remoting 5.0.0.Beta11

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2067?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2067: ------------------------------------- Summary: Upgrade to JBoss Remoting 5.0.0.Beta11 (was: Upgrade to JBoss Remoting 5.0.0.Beta10) > Upgrade to JBoss Remoting 5.0.0.Beta11 > -------------------------------------- > > Key: WFCORE-2067 > URL: https://issues.jboss.org/browse/WFCORE-2067 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha15 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2035) Authorization Failures Starting After Enabling RBAC

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2035?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2035: ------------------------------------- Fix Version/s: 3.0.0.Alpha15 > Authorization Failures Starting After Enabling RBAC > --------------------------------------------------- > > Key: WFCORE-2035 > URL: https://issues.jboss.org/browse/WFCORE-2035 > Project: WildFly Core > Issue Type: Bug > Components: JMX, Security > Reporter: Ingo Weiss > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha15 > > > Enabling RBAC on WildFly is causing authorization failures on reload and it remains in unusable state afterwards. It is not possible to use neither CLI or Web Console thus it is not possible to configure or control server in any way. > {noformat} > 2016-11-22 14:43:27,256 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaTransactionManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaTransactionManager: WFLYTX0006: Failed to configure object store browser bean > at org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:150) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access > at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1211) > at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1197) > at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:877) > at com.arjuna.ats.arjuna.tools.osb.util.JMXServer.registerMBean(JMXServer.java:120) > at com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser.start(ObjStoreBrowser.java:154) > at org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:148) > ... 5 more > {noformat} > {noformat} > 2016-11-22 14:43:27,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.ws.config: org.jboss.msc.service.StartException in service jboss.ws.config: javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access > at org.jboss.as.webservices.service.ServerConfigService.start(ServerConfigService.java:73) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access > at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1211) > at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1197) > at org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:877) > at org.jboss.ws.common.management.AbstractServerConfig.create(AbstractServerConfig.java:343) > at org.jboss.as.webservices.config.ServerConfigImpl.create(ServerConfigImpl.java:70) > at org.jboss.as.webservices.service.ServerConfigService.start(ServerConfigService.java:70) > ... 5 more > {noformat} > {noformat} > 2016-11-22 14:43:30,434 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.clustering.infinispan.cache-container.web: org.jboss.msc.service.StartException in service org.wildfly.clustering.infinispan.cache-container.web: org.infinispan.commons.CacheException: Failure while registering mbeans > at org.wildfly.clustering.service.FunctionalValueService.start(FunctionalValueService.java:69) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.infinispan.commons.CacheException: Failure while registering mbeans > at org.infinispan.jmx.ComponentsJmxRegistration.registerMBeans(ComponentsJmxRegistration.java:67) > at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:38) > at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:41) > at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:657) > at org.jboss.as.clustering.infinispan.subsystem.CacheContainerBuilder.lambda$build$3(CacheContainerBuilder.java:106) > at org.wildfly.clustering.service.SuppliedValueService.lambda$new$0(SuppliedValueService.java:42) > at org.wildfly.clustering.service.FunctionalValueService.start(FunctionalValueService.java:67) > ... 5 more > Caused by: javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access > at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1211) > at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1197) > at org.jboss.as.jmx.PluggableMBeanServerImpl.isRegistered(PluggableMBeanServerImpl.java:784) > at org.infinispan.jmx.JmxUtil.registerMBean(JmxUtil.java:66) > at org.infinispan.jmx.ComponentsJmxRegistration.registerMBeans(ComponentsJmxRegistration.java:64) > ... 11 more > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4539) logging statement to trace remoting heartbeat

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4539?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-4539: ----------------------------------- Issue Type: Enhancement (was: Feature Request) > logging statement to trace remoting heartbeat > --------------------------------------------- > > Key: WFLY-4539 > URL: https://issues.jboss.org/browse/WFLY-4539 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Affects Versions: JBoss AS7 7.2.0.Final > Reporter: Carsten Lichy-Bittendorf > Assignee: Peter Palaga > Priority: Minor > > you can set the heartbeat on a remoting connection by setting: > remote.connection.default.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL > What is missing is the option to log on the client when the heartbeat message is fired. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4539) logging statement to trace remoting heartbeat

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/WFLY-4539?page=com.atlassian.jira.plugin.... ] Peter Palaga commented on WFLY-4539: ------------------------------------ Assigned to me as agreed with [~tomekadamski] > logging statement to trace remoting heartbeat > --------------------------------------------- > > Key: WFLY-4539 > URL: https://issues.jboss.org/browse/WFLY-4539 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Affects Versions: JBoss AS7 7.2.0.Final > Reporter: Carsten Lichy-Bittendorf > Assignee: Peter Palaga > Priority: Minor > > you can set the heartbeat on a remoting connection by setting: > remote.connection.default.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL > What is missing is the option to log on the client when the heartbeat message is fired. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4539) logging statement to trace remoting heartbeat

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/WFLY-4539?page=com.atlassian.jira.plugin.... ] Peter Palaga reassigned WFLY-4539: ---------------------------------- Assignee: Peter Palaga (was: Tomasz Adamski) > logging statement to trace remoting heartbeat > --------------------------------------------- > > Key: WFLY-4539 > URL: https://issues.jboss.org/browse/WFLY-4539 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Affects Versions: JBoss AS7 7.2.0.Final > Reporter: Carsten Lichy-Bittendorf > Assignee: Peter Palaga > Priority: Minor > > you can set the heartbeat on a remoting connection by setting: > remote.connection.default.connect.options.org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL > What is missing is the option to log on the client when the heartbeat message is fired. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7722) looking for migration from jboss 5 to wildfly 10. Can we migrate app developed in jsf 2 with richfaces 3.3, to wildfly 10.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7722?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-7722. ------------------------------------ Assignee: Darran Lofthouse (was: Jason Greene) Resolution: Rejected Jira is for reporting bugs and feature requests, for general requests for assistance please use the user forums: - http://wildfly.org/gethelp/ > looking for migration from jboss 5 to wildfly 10. Can we migrate app developed in jsf 2 with richfaces 3.3, to wildfly 10. > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7722 > URL: https://issues.jboss.org/browse/WFLY-7722 > Project: WildFly > Issue Type: Feature Request > Affects Versions: 10.1.0.Final > Reporter: Bindu Mahapatra > Assignee: Darran Lofthouse > > Looking for migration from jboss 5 to wildfly 10. Can we migrate app developed in jsf 2 with richfaces 3.3, to wildfly 10, if yes can you please let me know the steps. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1375) TemplateModel.addRow() throws IlegalArgumentException with incorrect count

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1375?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-1375: -------------------------------- Description: The given method throws exception if the count of inserted columns differs from count of template variables. The problem is that the exception contains incorrect count of expected columns. (was: The given method throws exception if the amount of inserted columns differs from amount of template variables. The problem is that the exception contains incorrect amount of expected columns.) > TemplateModel.addRow() throws IlegalArgumentException with incorrect count > -------------------------------------------------------------------------- > > Key: DROOLS-1375 > URL: https://issues.jboss.org/browse/DROOLS-1375 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.0.0.Beta3 > Reporter: Jozef Marko > Assignee: Jozef Marko > Priority: Minor > Labels: reported-by-qe > > The given method throws exception if the count of inserted columns differs from count of template variables. The problem is that the exception contains incorrect count of expected columns. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 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 December 2016