December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7300) OperationHandlers that register DeploymentProcessor should do it only on boot

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-7300?page=com.atlassian.jira.plugin.... ] James Perkins edited comment on WFLY-7300 at 12/12/16 1:14 PM: --------------------------------------------------------------- I was able to duplicate this with the legacy {{batch}} subsystem. This is my fault as I was testing this with some other batch changes I'm working that includes a fix for this. I can either do a quick patch for this or we can wait, hopefully just this week, until I can send in a PR with other changes that will fix this. As far as a workaround goes if the {{batch-jberet}} subsystem is used the issue should disappear. The {{batch}} subsystem is deprecated anyway. was (Author: jamezp): I was able to duplicate this with the legacy {{batch}} subsystem. This is my fault as I was testing this with some other batch changes I'm working that includes a fix for this. I can either do a quick patch for this or we can wait, hopefully just this week, until I can send in a PR with other changes that will fix this. > OperationHandlers that register DeploymentProcessor should do it only on boot > ----------------------------------------------------------------------------- > > Key: WFLY-7300 > URL: https://issues.jboss.org/browse/WFLY-7300 > Project: WildFly > Issue Type: Bug > Reporter: ehsavoie Hugonnet > Assignee: James Perkins > Fix For: 11.0.0.Alpha1 > > > Registering a DeploymentProcessor is a boot only operation. Thus instead of extends AbstractAddStepHandler they should extend AbstractBoottimeAddStepHandler -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7300) OperationHandlers that register DeploymentProcessor should do it only on boot

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-7300?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFLY-7300: ------------------------------------- I was able to duplicate this with the legacy {{batch}} subsystem. This is my fault as I was testing this with some other batch changes I'm working that includes a fix for this. I can either do a quick patch for this or we can wait, hopefully just this week, until I can send in a PR with other changes that will fix this. > OperationHandlers that register DeploymentProcessor should do it only on boot > ----------------------------------------------------------------------------- > > Key: WFLY-7300 > URL: https://issues.jboss.org/browse/WFLY-7300 > Project: WildFly > Issue Type: Bug > Reporter: ehsavoie Hugonnet > Assignee: James Perkins > Fix For: 11.0.0.Alpha1 > > > Registering a DeploymentProcessor is a boot only operation. Thus instead of extends AbstractAddStepHandler they should extend AbstractBoottimeAddStepHandler -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7300) OperationHandlers that register DeploymentProcessor should do it only on boot

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-7300?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFLY-7300: ------------------------------------- Does WildFly Camel use an old configuration? I can see where this would be a problem if it uses the old {{batch}} subsystem and not the new {{batch-jberet}} subsystem. > OperationHandlers that register DeploymentProcessor should do it only on boot > ----------------------------------------------------------------------------- > > Key: WFLY-7300 > URL: https://issues.jboss.org/browse/WFLY-7300 > Project: WildFly > Issue Type: Bug > Reporter: ehsavoie Hugonnet > Assignee: James Perkins > Fix For: 11.0.0.Alpha1 > > > Registering a DeploymentProcessor is a boot only operation. Thus instead of extends AbstractAddStepHandler they should extend AbstractBoottimeAddStepHandler -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7300) OperationHandlers that register DeploymentProcessor should do it only on boot

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-7300?page=com.atlassian.jira.plugin.... ] James Perkins edited comment on WFLY-7300 at 12/12/16 1:01 PM: --------------------------------------------------------------- [~thomas.diesler] Does WildFly Camel use an old configuration? I can see where this would be a problem if it uses the old {{batch}} subsystem and not the new {{batch-jberet}} subsystem. was (Author: jamezp): Does WildFly Camel use an old configuration? I can see where this would be a problem if it uses the old {{batch}} subsystem and not the new {{batch-jberet}} subsystem. > OperationHandlers that register DeploymentProcessor should do it only on boot > ----------------------------------------------------------------------------- > > Key: WFLY-7300 > URL: https://issues.jboss.org/browse/WFLY-7300 > Project: WildFly > Issue Type: Bug > Reporter: ehsavoie Hugonnet > Assignee: James Perkins > Fix For: 11.0.0.Alpha1 > > > Registering a DeploymentProcessor is a boot only operation. Thus instead of extends AbstractAddStepHandler they should extend AbstractBoottimeAddStepHandler -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2145) UDP: investigate slow-down compared to TCP

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2145?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2145: -------------------------------- JGRP-2146 is another way to reduce sequential deserialization of messages in UDP. > UDP: investigate slow-down compared to TCP > ------------------------------------------ > > Key: JGRP-2145 > URL: https://issues.jboss.org/browse/JGRP-2145 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.1 > > > With IspnPerfTest, a UDP-based config is roughly 30% slower on cluster01-08 than a TCP-based config. Investigate why. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7300) OperationHandlers that register DeploymentProcessor should do it only on boot

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFLY-7300?page=com.atlassian.jira.plugin.... ] ehsavoie Hugonnet reassigned WFLY-7300: --------------------------------------- Assignee: James Perkins (was: ehsavoie Hugonnet) > OperationHandlers that register DeploymentProcessor should do it only on boot > ----------------------------------------------------------------------------- > > Key: WFLY-7300 > URL: https://issues.jboss.org/browse/WFLY-7300 > Project: WildFly > Issue Type: Bug > Reporter: ehsavoie Hugonnet > Assignee: James Perkins > Fix For: 11.0.0.Alpha1 > > > Registering a DeploymentProcessor is a boot only operation. Thus instead of extends AbstractAddStepHandler they should extend AbstractBoottimeAddStepHandler -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2145) UDP: investigate slow-down compared to TCP

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2145?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2145: -------------------------------- The reception of messages from potentially all members at the same time may create a bottleneck: currently, messages are de-serialized by the (unicast- or multicast-) thread _before_ passing them to the thread pool. This is contrary to TCP where we have one dedicated thread per member (connection), so other threads are not slowed down having to wait for de-serialization of messages from other members. Possibly revisit decision to do de-serialization on the receiver thread for UDP... > UDP: investigate slow-down compared to TCP > ------------------------------------------ > > Key: JGRP-2145 > URL: https://issues.jboss.org/browse/JGRP-2145 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.1 > > > With IspnPerfTest, a UDP-based config is roughly 30% slower on cluster01-08 than a TCP-based config. Investigate why. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2109) Require Maven 3.3.1+ and introduce mvnw

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2109?page=com.atlassian.jira.plugi... ] Peter Palaga updated WFCORE-2109: --------------------------------- Description: There are three closely related things here: * Maven 3.3.1+ is required by the Enforcer Plugin * mvnw (a.k.a. Maven Wrapper) is a script that downloads and installs (if necessary) the required Maven version to ~/.m2/wrapper and runs it from there. "mvn -N io.takari:maven:wrapper" was used to create all the necessary files. The same command can be used in the future to upgrade to a newer wrapper version. Maven version used by the wrapper is stored in .mvn/wrapper/maven-wrapper.properties * .mvn/jvm.config is a place where Maven 3.3.1+ looks for JVM parameters (memory, etc.) which were traditionally defined in the MAVEN_OPTS environment variable. > Require Maven 3.3.1+ and introduce mvnw > --------------------------------------- > > Key: WFCORE-2109 > URL: https://issues.jboss.org/browse/WFCORE-2109 > Project: WildFly Core > Issue Type: Task > Reporter: Peter Palaga > Assignee: Peter Palaga > > There are three closely related things here: > * Maven 3.3.1+ is required by the Enforcer Plugin > * mvnw (a.k.a. Maven Wrapper) is a script that downloads and installs > (if necessary) the required Maven version to ~/.m2/wrapper and runs it > from there. "mvn -N io.takari:maven:wrapper" was used to create all the > necessary files. The same command can be used in the future to upgrade > to a newer wrapper version. Maven version used by the wrapper is stored > in .mvn/wrapper/maven-wrapper.properties > * .mvn/jvm.config is a place where Maven 3.3.1+ looks for JVM parameters > (memory, etc.) which were traditionally defined in the MAVEN_OPTS > environment variable. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2109) Require Maven 3.3.1+ and introduce mvnw

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2109?page=com.atlassian.jira.plugi... ] Peter Palaga reassigned WFCORE-2109: ------------------------------------ Assignee: Peter Palaga > Require Maven 3.3.1+ and introduce mvnw > --------------------------------------- > > Key: WFCORE-2109 > URL: https://issues.jboss.org/browse/WFCORE-2109 > Project: WildFly Core > Issue Type: Task > Reporter: Peter Palaga > Assignee: Peter Palaga > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2109) Require Maven 3.3.1+ and introduce mvnw

by Peter Palaga (JIRA)

Peter Palaga created WFCORE-2109: ------------------------------------ Summary: Require Maven 3.3.1+ and introduce mvnw Key: WFCORE-2109 URL: https://issues.jboss.org/browse/WFCORE-2109 Project: WildFly Core Issue Type: Task Reporter: Peter Palaga -- 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