November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5617) JGroups transport protocol properties are never applied

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5617?page=com.atlassian.jira.plugin.... ] Paul Ferraro reassigned WFLY-5617: ---------------------------------- Assignee: Paul Ferraro (was: Radoslav Husar) > JGroups transport protocol properties are never applied > ------------------------------------------------------- > > Key: WFLY-5617 > URL: https://issues.jboss.org/browse/WFLY-5617 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Priority: Blocker > Labels: clustering_performance > Fix For: 10.0.0.Final > > > Introduced by > fc4c9b37391ac3eec51420b38b5f2a479d3a6a1e -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5617) JGroups transport protocol properties are never applied

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5617?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-5617: ------------------------------------ Consequently, our performance tests are running with a OOB thread pool max size of 10. The intended value is 300. That explains a lot. > JGroups transport protocol properties are never applied > ------------------------------------------------------- > > Key: WFLY-5617 > URL: https://issues.jboss.org/browse/WFLY-5617 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Blocker > Labels: clustering_performance > Fix For: 10.0.0.Final > > > Introduced by > fc4c9b37391ac3eec51420b38b5f2a479d3a6a1e -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5617) JGroups transport protocol properties are never applied

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5617?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-5617: --------------------------------- Labels: clustering_performance (was: ) > JGroups transport protocol properties are never applied > ------------------------------------------------------- > > Key: WFLY-5617 > URL: https://issues.jboss.org/browse/WFLY-5617 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Blocker > Labels: clustering_performance > Fix For: 10.0.0.Final > > > Introduced by > fc4c9b37391ac3eec51420b38b5f2a479d3a6a1e -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5617) JGroups transport protocol properties are never applied

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-5617: ------------------------------------ Summary: JGroups transport protocol properties are never applied Key: WFLY-5617 URL: https://issues.jboss.org/browse/WFLY-5617 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.CR4 Reporter: Radoslav Husar Assignee: Radoslav Husar Priority: Blocker Fix For: 10.0.0.Final Introduced by fc4c9b37391ac3eec51420b38b5f2a479d3a6a1e -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-359) Additional work on LDAP SecurityRealm

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-359: ------------------------------------ Summary: Additional work on LDAP SecurityRealm Key: ELY-359 URL: https://issues.jboss.org/browse/ELY-359 Project: WildFly Elytron Issue Type: Enhancement Components: Realms Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta2 The credential loaders need to be created outside of the realm instance, this way multiple instances can be created with varying settings. The PrincipalMapping class was only really intended to contain settings required to locate a prinicipal - however this has ended up containing credential loading settings. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1825) ReadWriteLock

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1825?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1825: -------------------------------- What exactly do you want to achieve? Can't you implement the locking/isolation semantics with cache-local locks and using JGroups only as message transport? I'm not entirely happy with the current {{LockService}}, as it doesn't handle partitions well. The {{j.u.c.l.Lock}} interface isn't amenable to takeing locks away from members, so I'm thinking about designing a new partitionable lock service. Not at the top of my todo list though... Since I'm not happy with the current lock impl, I don't want to add something atm. > ReadWriteLock > ------------- > > Key: JGRP-1825 > URL: https://issues.jboss.org/browse/JGRP-1825 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6 > > Attachments: JgroupTest.zip > > > Adds a read/write lock to LockService. The impl is attached -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1033) ManagedDatagramSocketBinding and ManagedMulticastSocketBinding throw NPE if created with bind address

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1033?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1033: ------------------------------------------------- Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from ON_QA to ASSIGNED > ManagedDatagramSocketBinding and ManagedMulticastSocketBinding throw NPE if created with bind address > ----------------------------------------------------------------------------------------------------- > > Key: WFCORE-1033 > URL: https://issues.jboss.org/browse/WFCORE-1033 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > Fix For: 2.0.0.CR7 > > > {noformat} > &amp#27;[0m&amp#27;[31m14:51:47,114 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector: java.lang.NullPointerException > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:96) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > 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: java.lang.NullPointerException > at org.jboss.as.network.ManagedMulticastSocketBinding.bind(ManagedMulticastSocketBinding.java:78) > at java.net.MulticastSocket.<init>(MulticastSocket.java:172) > at org.jboss.as.network.ManagedMulticastSocketBinding.<init>(ManagedMulticastSocketBinding.java:54) > at org.jboss.as.network.ManagedMulticastSocketBinding.create(ManagedMulticastSocketBinding.java:40) > at org.jboss.as.network.SocketBindingManagerImpl.createMulticastSocket(SocketBindingManagerImpl.java:82) > at org.jboss.as.clustering.jgroups.ManagedSocketFactoryNew.createMulticastSocket(ManagedSocketFactoryNew.java:127) > at org.jgroups.util.Util.createMulticastSocket(Util.java:3089) > at org.jgroups.protocols.MPING.start(MPING.java:190) > at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965) > at org.jgroups.JChannel.startStack(JChannel.java:890) > at org.jgroups.JChannel._preConnect(JChannel.java:553) > at org.jgroups.JChannel.connect(JChannel.java:288) > at org.jgroups.JChannel.connect(JChannel.java:279) > at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94) > {noformat} > This is because the MulticastSocket and DatagramSocket constructors call bind(...), but the ManagedBindingRegistry is not yet set. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5449) Custom socket factory for JGroups subsystem not set correctly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5449?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5449: ----------------------------------------------- Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from ON_QA to ASSIGNED > Custom socket factory for JGroups subsystem not set correctly > ------------------------------------------------------------- > > Key: WFLY-5449 > URL: https://issues.jboss.org/browse/WFLY-5449 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR2 > Reporter: Dennis Reed > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 10.0.0.CR4 > > > Wildfly's JChannelFactory tries to set a custom socket factory on the JGroups transport. > This is not the correct API to use, and it gets overwritten when the JGroups channel starts. > A custom socket factory should be set on the JChannel. > The only time the custom socket factory is currently used is if there's a race condition where two channels are started at the same time, and the custom factory is set just before the other channel uses it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1064) Creating named multicast socket doesn't properly register socket using name

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1064?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1064: ------------------------------------------------- Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from ON_QA to ASSIGNED > Creating named multicast socket doesn't properly register socket using name > --------------------------------------------------------------------------- > > Key: WFCORE-1064 > URL: https://issues.jboss.org/browse/WFCORE-1064 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR7 > Reporter: Paul Ferraro > Assignee: Brian Stansberry > Fix For: 2.0.0.CR8 > > > I'm not sure why this is, but the socket binding manager ignores the name of the multicast socket and registers the socket using the unnamed registry. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1063) Creating named datagram socket throws ISE

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1063?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1063: ------------------------------------------------- Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1268185|https://bugzilla.redhat.com/show_bug.cgi?id=1268185] from ON_QA to ASSIGNED > Creating named datagram socket throws ISE > ----------------------------------------- > > Key: WFCORE-1063 > URL: https://issues.jboss.org/browse/WFCORE-1063 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR7 > Reporter: Paul Ferraro > Assignee: Brian Stansberry > Fix For: 2.0.0.CR8 > > > The DatagramSocket createDatagramSocket(String name, SocketAddress address) method of org.jboss.as.network.SocketBindingManagerImpl creates a ManagedDatagramSocketBinding with a null name, yet registers the socket using the NamedManagedBindingRegistry. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 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 November 2015