October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-258) drools-camel-server and guvnor-webapp: Do not use the dependency cxf-bundle-jaxrs because it's an uber jar that disrupts our dependency graph

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-258?page=com.atlassian.jira.plugin... ] Petr Široký resolved DROOLS-258. -------------------------------- Assignee: Petr Široký (was: Michael Biarnes Kiefer) Fix Version/s: 6.2.0.Final Resolution: Done > drools-camel-server and guvnor-webapp: Do not use the dependency cxf-bundle-jaxrs because it's an uber jar that disrupts our dependency graph > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-258 > URL: https://issues.jboss.org/browse/DROOLS-258 > Project: Drools > Issue Type: Bug > Reporter: Geoffrey De Smet > Assignee: Petr Široký > Priority: Critical > Fix For: 6.2.0.Final > > > cxf-bundle-jaxrs isn't mentioned in here: > http://cxf.apache.org/docs/using-cxf-with-maven.html > it pulls in a lot we don't need and we try to exclude what we don't need (but fail at it). > Furher proof that cxf-bundle-jaxrs is evil: > http://svn.apache.org/repos/asf/cxf/trunk/distribution/bundle/jaxrs/pom.xml > It uses the maven-shade-plugin, which is a blocker for the Red Hat re-packers team (see fosdem 2011 presentation) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-258) drools-camel-server and guvnor-webapp: Do not use the dependency cxf-bundle-jaxrs because it's an uber jar that disrupts our dependency graph

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-258?page=com.atlassian.jira.plugin... ] Petr Široký commented on DROOLS-258: ------------------------------------ The {{cxf-bundle-jaxrs}} has been removed from the kie-camel and drools-camel-server-example: https://github.com/droolsjbpm/droolsjbpm-integration/pull/102 The {{org.apache.cxf:cxf-bundle-jaxrs}} is now banned from usage using the maven enforcer plugin. See https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/pull/54. This means we should not hit any similar issue in future regarding this uberjar. > drools-camel-server and guvnor-webapp: Do not use the dependency cxf-bundle-jaxrs because it's an uber jar that disrupts our dependency graph > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-258 > URL: https://issues.jboss.org/browse/DROOLS-258 > Project: Drools > Issue Type: Bug > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > Fix For: 6.2.0.Final > > > cxf-bundle-jaxrs isn't mentioned in here: > http://cxf.apache.org/docs/using-cxf-with-maven.html > it pulls in a lot we don't need and we try to exclude what we don't need (but fail at it). > Furher proof that cxf-bundle-jaxrs is evil: > http://svn.apache.org/repos/asf/cxf/trunk/distribution/bundle/jaxrs/pom.xml > It uses the maven-shade-plugin, which is a blocker for the Red Hat re-packers team (see fosdem 2011 presentation) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1887) Remove the synchronization on JChannel.class in JChannel.init

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1887?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1887. ---------------------------- Resolution: Done > Remove the synchronization on JChannel.class in JChannel.init > ------------------------------------------------------------- > > Key: JGRP-1887 > URL: https://issues.jboss.org/browse/JGRP-1887 > Project: JGroups > Issue Type: Task > Affects Versions: 3.5.1 > Reporter: Dan Berindei > Assignee: Bela Ban > Fix For: 3.5.2, 3.6 > > > {{JChannel.init(ProtocolCtackConfigurator)}} has a {{synchronized(Channel.class)}} block that doesn't seem necessary, as JChannel instances do not normally share resources. > This can cause serious delays in the Infinispan test suite, because we run many tests in parallel, each creating its own cluster. In some tests we also have a timeout for the test to create the JChannel (among other things), and these delays can lead to random failures (e.g. ISPN-4802). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1887) Remove the synchronization on JChannel.class in JChannel.init

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1887?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1887 at 10/6/14 6:50 AM: --------------------------------------------------------- h4. Solution * Remove the synchronization around {{JChannel.init()}} * In {{ProtocolStack.initProtocolStack()}}, move calling {{init()}} inside the lock scope if we have a shared transport. This way, the first channel creation will synchronize around creation of the shared transport, but subsequent creations won't. Also, subsequent creations will find a fully initialized shared transport. Note that this does not affect non-shared transports. was (Author: belaban): h4. Solution * Remove the synchronization around {{JChannel.init()}} * In {{ProtocolStack.initProtocolStack()}}, move calling {{init()}} inside the lock scope if we have a shared transport. This way, the first channel creation will synchronize around creation of the shared transport, but subsequent creations won't. Also, subsequent creations will find a fully initialized shared transport. > Remove the synchronization on JChannel.class in JChannel.init > ------------------------------------------------------------- > > Key: JGRP-1887 > URL: https://issues.jboss.org/browse/JGRP-1887 > Project: JGroups > Issue Type: Task > Affects Versions: 3.5.1 > Reporter: Dan Berindei > Assignee: Bela Ban > Fix For: 3.5.2, 3.6 > > > {{JChannel.init(ProtocolCtackConfigurator)}} has a {{synchronized(Channel.class)}} block that doesn't seem necessary, as JChannel instances do not normally share resources. > This can cause serious delays in the Infinispan test suite, because we run many tests in parallel, each creating its own cluster. In some tests we also have a timeout for the test to create the JChannel (among other things), and these delays can lead to random failures (e.g. ISPN-4802). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1887) Remove the synchronization on JChannel.class in JChannel.init

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1887?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1887 at 10/6/14 6:49 AM: --------------------------------------------------------- h4. Solution * Remove the synchronization around {{JChannel.init()}} * In {{ProtocolStack.initProtocolStack()}}, move calling {{init()}} inside the lock scope if we have a shared transport. This way, the first channel creation will synchronize around creation of the shared transport, but subsequent creations won't. Also, subsequent creations will find a fully initialized shared transport. was (Author: belaban): h4. Solution * Remove the synchronization around {{JChannel.init()} * In {{ProtocolStack.initProtocolStack()}}, move calling {{init()}} inside the lock scope if we have a shared transport. This way, the first channel creation will synchronize around creation of the shared transport, but subsequent creations won't. Also, subsequent creations will find a fully initialized shared transport. > Remove the synchronization on JChannel.class in JChannel.init > ------------------------------------------------------------- > > Key: JGRP-1887 > URL: https://issues.jboss.org/browse/JGRP-1887 > Project: JGroups > Issue Type: Task > Affects Versions: 3.5.1 > Reporter: Dan Berindei > Assignee: Bela Ban > Fix For: 3.5.2, 3.6 > > > {{JChannel.init(ProtocolCtackConfigurator)}} has a {{synchronized(Channel.class)}} block that doesn't seem necessary, as JChannel instances do not normally share resources. > This can cause serious delays in the Infinispan test suite, because we run many tests in parallel, each creating its own cluster. In some tests we also have a timeout for the test to create the JChannel (among other things), and these delays can lead to random failures (e.g. ISPN-4802). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1887) Remove the synchronization on JChannel.class in JChannel.init

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1887?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1887: -------------------------------- h4. Solution * Remove the synchronization around {{JChannel.init()} * In {{ProtocolStack.initProtocolStack()}}, move calling {{init()}} inside the lock scope if we have a shared transport. This way, the first channel creation will synchronize around creation of the shared transport, but subsequent creations won't. Also, subsequent creations will find a fully initialized shared transport. > Remove the synchronization on JChannel.class in JChannel.init > ------------------------------------------------------------- > > Key: JGRP-1887 > URL: https://issues.jboss.org/browse/JGRP-1887 > Project: JGroups > Issue Type: Task > Affects Versions: 3.5.1 > Reporter: Dan Berindei > Assignee: Bela Ban > Fix For: 3.5.2, 3.6 > > > {{JChannel.init(ProtocolCtackConfigurator)}} has a {{synchronized(Channel.class)}} block that doesn't seem necessary, as JChannel instances do not normally share resources. > This can cause serious delays in the Infinispan test suite, because we run many tests in parallel, each creating its own cluster. In some tests we also have a timeout for the test to create the JChannel (among other things), and these delays can lead to random failures (e.g. ISPN-4802). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1887) Remove the synchronization on JChannel.class in JChannel.init

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1887?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1887 at 10/6/14 6:04 AM: --------------------------------------------------------- Cause: https://issues.jboss.org/browse/JGRP-964, related to shared transport. When multiple channels are started in parallel, the first channel creates the shared transport. However, subsequent channels might fail accessing the shared transport's fields (such as the timer), as the shared transport hasn't yet been fully created (e.g. the timer hasn't yet been instantiated). was (Author: belaban): Cause: https://issues.jboss.org/browse/JGRP-964. Need to investigate whether this is still needed. > Remove the synchronization on JChannel.class in JChannel.init > ------------------------------------------------------------- > > Key: JGRP-1887 > URL: https://issues.jboss.org/browse/JGRP-1887 > Project: JGroups > Issue Type: Task > Affects Versions: 3.5.1 > Reporter: Dan Berindei > Assignee: Bela Ban > Fix For: 3.5.2, 3.6 > > > {{JChannel.init(ProtocolCtackConfigurator)}} has a {{synchronized(Channel.class)}} block that doesn't seem necessary, as JChannel instances do not normally share resources. > This can cause serious delays in the Infinispan test suite, because we run many tests in parallel, each creating its own cluster. In some tests we also have a timeout for the test to create the JChannel (among other things), and these delays can lead to random failures (e.g. ISPN-4802). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1887) Remove the synchronization on JChannel.class in JChannel.init

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1887?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1887: -------------------------------- Cause: https://issues.jboss.org/browse/JGRP-964. Need to investigate whether this is still needed. > Remove the synchronization on JChannel.class in JChannel.init > ------------------------------------------------------------- > > Key: JGRP-1887 > URL: https://issues.jboss.org/browse/JGRP-1887 > Project: JGroups > Issue Type: Task > Affects Versions: 3.5.1 > Reporter: Dan Berindei > Assignee: Bela Ban > Fix For: 3.5.2, 3.6 > > > {{JChannel.init(ProtocolCtackConfigurator)}} has a {{synchronized(Channel.class)}} block that doesn't seem necessary, as JChannel instances do not normally share resources. > This can cause serious delays in the Infinispan test suite, because we run many tests in parallel, each creating its own cluster. In some tests we also have a timeout for the test to create the JChannel (among other things), and these delays can lead to random failures (e.g. ISPN-4802). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1149623|https://bugzilla.redhat.com/show_bug.cgi?id=1149623] from NEW to CLOSED > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-112: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1149618, https://bugzilla.redhat.com/show_bug.cgi?id=1149623 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1149618) > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 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 2014