January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-790) FD_SOCK / shared transport: make FD_SOCK a singleton

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-790?page=com.atlassian.jira.plugin.s... ] Bela Ban closed JGRP-790. ------------------------- Resolution: Done This is not needed anymore, with fork channels we only have 1 FD_SOCK protocol > FD_SOCK / shared transport: make FD_SOCK a singleton > ---------------------------------------------------- > > Key: JGRP-790 > URL: https://issues.jboss.org/browse/JGRP-790 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.8 > > > If we have multiple channels over the same shared transport, FD_SOCK creates multiple server sockets within the same JVM. Investigate whether we can collapse those into one server socket if we run over the same shared transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-790) FD_SOCK / shared transport: make FD_SOCK a singleton

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-790?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-790: -------------------------- Fix Version/s: 3.6.8 (was: Future) > FD_SOCK / shared transport: make FD_SOCK a singleton > ---------------------------------------------------- > > Key: JGRP-790 > URL: https://issues.jboss.org/browse/JGRP-790 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.8 > > > If we have multiple channels over the same shared transport, FD_SOCK creates multiple server sockets within the same JVM. Investigate whether we can collapse those into one server socket if we run over the same shared transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-640) Shared protocols

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-640?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-640: -------------------------- Fix Version/s: 3.6.8 (was: Future) > Shared protocols > ---------------- > > Key: JGRP-640 > URL: https://issues.jboss.org/browse/JGRP-640 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.8 > > > Like the shared transport, investigate whether we can share other protocols. E.g. FD, FD_SOCK (preventing duplicate server sockets and sockets), Discovery and so on. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-640) Shared protocols

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-640?page=com.atlassian.jira.plugin.s... ] Bela Ban closed JGRP-640. ------------------------- Resolution: Done Use of fork channels obliviated this topic > Shared protocols > ---------------- > > Key: JGRP-640 > URL: https://issues.jboss.org/browse/JGRP-640 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.8 > > > Like the shared transport, investigate whether we can share other protocols. E.g. FD, FD_SOCK (preventing duplicate server sockets and sockets), Discovery and so on. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-155) TP.loopback should always be used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-155?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-155: -------------------------- Fix Version/s: 3.6.8 (was: Future) > TP.loopback should always be used > --------------------------------- > > Key: JGRP-155 > URL: https://issues.jboss.org/browse/JGRP-155 > Project: JGroups > Issue Type: Task > Affects Versions: 2.2.8, 2.2.9 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.8 > > > Investigate the 3 potential problem areas below: > - Memory leak caused by FC when credits are received too quickly > - Deadlocks caused by same threads calling themselves (e.g. VIEW_OK ack msgs) > - Preemption doesn't work: Scheduler is meaningless here -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5898) JMS client BOM needs to include Apache Commons BeanUtils

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFLY-5898?page=com.atlassian.jira.plugin.... ] Miroslav Novak commented on WFLY-5898: -------------------------------------- It would be great, I don't know how to run this test suite. > JMS client BOM needs to include Apache Commons BeanUtils > -------------------------------------------------------- > > Key: WFLY-5898 > URL: https://issues.jboss.org/browse/WFLY-5898 > Project: WildFly > Issue Type: Bug > Components: Application Client, JMS > Affects Versions: 10.0.0.CR4 > Environment: Wildfly 10.0.0.CR4 > Reporter: Juraci Paixão Kröhling > Assignee: Jeff Mesnil > Fix For: 10.0.0.CR5 > > > When using the JMS client BOM, the following exception happens, due to the missing transitive dependency on Apache Commons BeanUtils > {code} > Exception in thread "naming-client-message-receiver-1-thread-1" java.lang.NoClassDefFoundError: org/apache/commons/beanutils/BeanIntrospector > at org.apache.activemq.artemis.uri.ConnectionFactoryParser.<init>(ConnectionFactoryParser.java:26) > at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:173) > at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.<init>(ActiveMQConnectionFactory.java:169) > ... > {code} > As a workaround, the consumer of the BOM may to add the following dependency: > {code} > <dependency> > <groupId>commons-beanutils</groupId> > <artifactId>commons-beanutils</artifactId> > <version>1.9.2</version> > <scope>test</scope> > </dependency> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-155) TP.loopback should always be used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-155?page=com.atlassian.jira.plugin.s... ] Bela Ban resolved JGRP-155. --------------------------- Resolution: Done This was fixed a long time ago, but was just moved from 4 -> 3.6.8, in order to be resolved. > TP.loopback should always be used > --------------------------------- > > Key: JGRP-155 > URL: https://issues.jboss.org/browse/JGRP-155 > Project: JGroups > Issue Type: Task > Affects Versions: 2.2.8, 2.2.9 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.8 > > > Investigate the 3 potential problem areas below: > - Memory leak caused by FC when credits are received too quickly > - Deadlocks caused by same threads calling themselves (e.g. VIEW_OK ack msgs) > - Preemption doesn't work: Scheduler is meaningless here -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-120) Static interface methods in Logger interface requires annotation

by Radim Vansa (JIRA)

Radim Vansa created JBLOGGING-120: ------------------------------------- Summary: Static interface methods in Logger interface requires annotation Key: JBLOGGING-120 URL: https://issues.jboss.org/browse/JBLOGGING-120 Project: JBoss Logging Issue Type: Bug Components: jboss-logging-logmanager Affects Versions: 3.3.0.Beta1 Reporter: Radim Vansa Assignee: James Perkins When I want to add a static helper method to the interface used for message logger, I get an error about requiring the @Message annotation. I think that this should not be required for static methods. My usecase: {code} @MessageLogger(projectCode = "FOO") public interface FooMessageLogger extends BasicLogger { static FooMessageLogger getLog(Class clazz) { return Logger.getMessageLogger(FooMessageLogger.class, clazz.getName()); } /* regular annotated logging methods */ } {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-100) Large-scale JGroups

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-100?page=com.atlassian.jira.plugin.s... ] Bela Ban closed JGRP-100. ------------------------- Resolution: Done Ran JGroups cluster of 2000+ nodes on Google Compute Engine (see YouTube channel) > Large-scale JGroups > ------------------- > > Key: JGRP-100 > URL: https://issues.jboss.org/browse/JGRP-100 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.8 > > > - Run JGroups on hundreds of nodes (either physical, or simulation). > - Determine a protocol stack that can be used for large-scale execution > - Example: > - Coordinator may be SPOF. If coord is hung, messages will be sent, but no new views will > be generated > - Retransmission: retransmit from anyone (not sender, otherwise we have NAK implosion) > - Look at PBCAST -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-100) Large-scale JGroups

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-100?page=com.atlassian.jira.plugin.s... ] Bela Ban updated JGRP-100: -------------------------- Fix Version/s: 3.6.8 (was: Future) > Large-scale JGroups > ------------------- > > Key: JGRP-100 > URL: https://issues.jboss.org/browse/JGRP-100 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.8 > > > - Run JGroups on hundreds of nodes (either physical, or simulation). > - Determine a protocol stack that can be used for large-scale execution > - Example: > - Coordinator may be SPOF. If coord is hung, messages will be sent, but no new views will > be generated > - Retransmission: retransmit from anyone (not sender, otherwise we have NAK implosion) > - Look at PBCAST -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 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 January 2016