October 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1962) Do not include the log4j2.xml resource in the released JGroups jar

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1962?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1962: -------------------------------- OK, I removed log4j2.xml and README from the JAR file. > Do not include the log4j2.xml resource in the released JGroups jar > ------------------------------------------------------------------ > > Key: JGRP-1962 > URL: https://issues.jboss.org/browse/JGRP-1962 > Project: JGroups > Issue Type: Task > Affects Versions: 3.6.4 > Reporter: Sanne Grinovero > Assignee: Bela Ban > Fix For: 3.6.6 > > > The {{log4j2.xml}} configuration file is included in JGroups, but this makes it hard to override the logging as this will likely conflict with other resources configured by end user applications. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1844) Remove shared transport

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1844: -------------------------------- I'll take a look at your explanation when I tackle this issue, but I can already tell you if this is an Infinispan issue, then it won't prevent me from removing the shared transport. In the worst casem you could always create full channels (with non-shared transports). No, FORK cannot be placed below GMS, or other protocols such as NAKACK2 or UNICAST3. It is really meant to be located towards the top of the stack. > Remove shared transport > ----------------------- > > Key: JGRP-1844 > URL: https://issues.jboss.org/browse/JGRP-1844 > Project: JGroups > Issue Type: Task > Affects Versions: 3.5 > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > I'm thinking of deprecating the shared transport [1] and remove it in 4.0. The replacement would be fork channels [2]. > Here's my reasoning: > * Shared transports are quite a complex beast: initialization (ref counting), cluster-name and local-addr are not used in TP when shared, duplicate logic. Removing this will make the code base smaller > * All protocols *above* shared transports are not shared, e.g. FD_SOCK, NAKACK, UNICAST etc all maintain their own threads, retransmission tables, sockets etc. With fork channels, everything up to the FORK protocol *is* shared > * TUNNEL doesn't work with shared transports (throws an exception) > * Hidden insertion of TP$ProtocolAdapter into the stack when shared transports are used > * Unneeded cost of sending N-1 messages (e.g. with TCP). Currently we send a message with dest null and no IP multicast capable transport to all physical addresses in the transport, which is a waste > Thoughts ? My +100 for removing shared transports in 4.0... > [1] http://www.jgroups.org/manual/html/user-advanced.html#SharedTransport > [2] http://www.jgroups.org/manual/html/user-advanced.html#ForkChannel -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5450) Update to Hibernate Core 5.0.2.Final

by Martin Kamp Jensen (JIRA)

Martin Kamp Jensen created WFLY-5450: ---------------------------------------- Summary: Update to Hibernate Core 5.0.2.Final Key: WFLY-5450 URL: https://issues.jboss.org/browse/WFLY-5450 Project: WildFly Issue Type: Component Upgrade Reporter: Martin Kamp Jensen Assignee: Jason Greene Fix For: 10.0.0.Final Please, if possible, include the latest Hibernate Core bugfix release in the final version of WildFly 10. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-929) CLI is terminated unexpectedly after type "qui" on HPUX

by Dominik Pospisil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-929?page=com.atlassian.jira.plugin... ] Dominik Pospisil commented on WFCORE-929: ----------------------------------------- My findings so far: * Actually It's typing the 'u' character making the JVM to terminate * The "Aesh InputStream Reader" seems to be causing the termination * it happends somewhere on line AeshInputStream.readFromStream:126, it does not make it to line 127. Seems to be somewhere in JDK code. > CLI is terminated unexpectedly after type "qui" on HPUX > ------------------------------------------------------- > > Key: WFCORE-929 > URL: https://issues.jboss.org/browse/WFCORE-929 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 2.0.0.Beta4 > Reporter: Marek Kopecký > Assignee: Alexey Loubyansky > Priority: Minor > > *Description of problem:* > CLI is terminated unexpectedly after type "qui" on HPUX > *How reproducible:* > Always on HPUX > *Steps to Reproduce:* > # ./standalone.sh > # ./jboss-cli.sh -c > # qui > #* type "qui" in console to CLI, do not press "enter" > *Actual results:* > CLI is terminated > *Expected results:* > CLI is not terminated -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1029) ManagedSocketFactory doesn't work for client sockets

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1029?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration updated WFCORE-1029: -------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1268186 Bugzilla Update: Perform > ManagedSocketFactory doesn't work for client sockets > ---------------------------------------------------- > > Key: WFCORE-1029 > URL: https://issues.jboss.org/browse/WFCORE-1029 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 2.0.0.CR5 > Reporter: Dennis Reed > > SocketBindingManagerImpl does not work with client sockets. > It adds sockets to a map based on local address. Client sockets that have not been bound yet do not have a local address. > This breaks the JGroups subsystem's ManagedSocketFactory, which uses SocketBindingManagerImpl for both server and client sockets. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 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 updated WFLY-5449: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1268185 Bugzilla Update: Perform > 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 > > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1029) ManagedSocketFactory doesn't work for client sockets

by Dennis Reed (JIRA)

Dennis Reed created WFCORE-1029: ----------------------------------- Summary: ManagedSocketFactory doesn't work for client sockets Key: WFCORE-1029 URL: https://issues.jboss.org/browse/WFCORE-1029 Project: WildFly Core Issue Type: Bug Affects Versions: 2.0.0.CR5 Reporter: Dennis Reed SocketBindingManagerImpl does not work with client sockets. It adds sockets to a map based on local address. Client sockets that have not been bound yet do not have a local address. This breaks the JGroups subsystem's ManagedSocketFactory, which uses SocketBindingManagerImpl for both server and client sockets. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

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

by Dennis Reed (JIRA)

Dennis Reed created WFLY-5449: --------------------------------- Summary: 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 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1026) Upgrade jboss-logmanager from 2.0.0.Final to 2.0.2.Final

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1026?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-1026: ---------------------------------- Summary: Upgrade jboss-logmanager from 2.0.0.Final to 2.0.2.Final (was: Upgrade jboss-logmanager from 2.0.0.Final to 2.0.1.Final) > Upgrade jboss-logmanager from 2.0.0.Final to 2.0.2.Final > -------------------------------------------------------- > > Key: WFCORE-1026 > URL: https://issues.jboss.org/browse/WFCORE-1026 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.0.0.CR6 > > > Bug found in the syslog handler where an extra 0 was being appended to October in the date formatter. https://issues.jboss.org/browse/LOGMGR-122. The 2.0.1.Final release only contains that fix. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1026) Upgrade jboss-logmanager from 2.0.0.Final to 2.0.2.Final

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1026?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-1026: ---------------------------------- Description: Bug found in the syslog handler where an extra 0 was being appended to October in the date formatter. https://issues.jboss.org/browse/LOGMGR-122. (was: Bug found in the syslog handler where an extra 0 was being appended to October in the date formatter. https://issues.jboss.org/browse/LOGMGR-122. The 2.0.1.Final release only contains that fix.) > Upgrade jboss-logmanager from 2.0.0.Final to 2.0.2.Final > -------------------------------------------------------- > > Key: WFCORE-1026 > URL: https://issues.jboss.org/browse/WFCORE-1026 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.0.0.CR6 > > > Bug found in the syslog handler where an extra 0 was being appended to October in the date formatter. https://issues.jboss.org/browse/LOGMGR-122. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 9 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 October 2015