September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3788) Upgrade org.apache.httpcomponents:httpclient to 4.3.2

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/WFLY-3788?page=com.atlassian.jira.plugin.... ] Jim Ma resolved WFLY-3788. -------------------------- Resolution: Done https://github.com/wildfly/wildfly/pull/6642 > Upgrade org.apache.httpcomponents:httpclient to 4.3.2 > ----------------------------------------------------- > > Key: WFLY-3788 > URL: https://issues.jboss.org/browse/WFLY-3788 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 8.1.0.Final > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: 9.0.0.Final > > > Webservice needs this upgrade to enable asynchronous client http transport in cxf 3.x. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1875) UNICAST3/UNICAST2: sync receiver table with sender table

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1875?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1875 at 9/1/14 2:22 AM: -------------------------------------------------------- We don't need the last {{SYNC-ACK}} message: this is only used to tell the sender to accept {{ACK}} msgss again, but when a sender receives a {{SYNC}} message, it changes its {{conn-id}} which automatically drops all messages from a receiver anyway ! The complete design document is here: https://github.com/belaban/JGroups/blob/master/doc/design/UNICAST3-SYNC.txt was (Author: belaban): We don't need the last {{SYNC-ACK}} message: this is only used to tell the sender to accept {{ACK}} msgss again, but when a sender receives a {{SYNC}} mesage, it changes its {{conn-id}} which automatically drops all messages from a receiver anyway ! The complete design document is here: https://github.com/belaban/JGroups/blob/master/doc/design/UNICAST3-SYNC.txt > UNICAST3/UNICAST2: sync receiver table with sender table > -------------------------------------------------------- > > Key: JGRP-1875 > URL: https://issues.jboss.org/browse/JGRP-1875 > Project: JGroups > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.1, 3.6 > > > If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}). > To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g. > * B needs to get the lowest and highest seqno sent from A > * B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message) > * B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}} > * B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos > * B creates an entry for A with the lowest and highest seqnos > * B sends a {{SYNC-ACK}} to A > * A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again > * A and B now use the usual protocols to retransmit missing messages -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1875) UNICAST3/UNICAST2: sync receiver table with sender table

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1875?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1875 at 9/1/14 2:22 AM: -------------------------------------------------------- We don't need the last {{SYNC-ACK}} message: this is only used to tell the sender to accept {{ACK}} msgss again, but when a sender receives a {{SYNC}} mesage, it changes its {{conn-id}} which automatically drops all messages from a receiver anyway ! The complete design document is here: https://github.com/belaban/JGroups/blob/master/doc/design/UNICAST3-SYNC.txt was (Author: belaban): We don't need the last {{SYNC-ACK}} message: this is only used to tell the sender to accept {{ACK}}s again, but when a sender receives a {{SYNC}} mesage, it changes its {{conn-id}} which automatically drops all messages from a receiver anyway ! The complete design document is here: https://github.com/belaban/JGroups/blob/master/doc/design/UNICAST3-SYNC.txt > UNICAST3/UNICAST2: sync receiver table with sender table > -------------------------------------------------------- > > Key: JGRP-1875 > URL: https://issues.jboss.org/browse/JGRP-1875 > Project: JGroups > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.1, 3.6 > > > If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}). > To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g. > * B needs to get the lowest and highest seqno sent from A > * B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message) > * B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}} > * B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos > * B creates an entry for A with the lowest and highest seqnos > * B sends a {{SYNC-ACK}} to A > * A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again > * A and B now use the usual protocols to retransmit missing messages -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1875) UNICAST3/UNICAST2: sync receiver table with sender table

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1875?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1875: -------------------------------- We don't need the last {{SYNC-ACK}} message: this is only used to tell the sender to accept {{ACK}}s again, but when a sender receives a {{SYNC}} mesage, it changes its {{conn-id}} which automatically drops all messages from a receiver anyway ! The complete design document is here: https://github.com/belaban/JGroups/blob/master/doc/design/UNICAST3-SYNC.txt > UNICAST3/UNICAST2: sync receiver table with sender table > -------------------------------------------------------- > > Key: JGRP-1875 > URL: https://issues.jboss.org/browse/JGRP-1875 > Project: JGroups > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.1, 3.6 > > > If a receiver B closes its recv-table and the sender A doesn't, then (when receiving msgs from the sender) the receiver engages in a protocol using {{GET-FIRST-SEQNO}} to sync itself with the sender. This has several problems, detailed in JGRP-1873 and JGRP-1874. (Note that the other way round (sender closing send-table), there is no issue, as the sender will create a new connection with a new {{conn-id}}). > To prevent {{STABLE}} messages interfering with {{GET-FIRST-SEQNO}} messages (JGRP-1873), we could run an additional {{SYNC}} protocol round, e.g. > * B needs to get the lowest and highest seqno sent from A > * B sends a {{SYNC}} message to A (instead of a {{GET-FIRST-SEQNO}} message) > * B sets a flag that discards all {{STABLE}} or {{ACK}} messages on reception of {{SYNC}} > * B replies with a {{SYNC-OK}} containing the _lowest_ and _highest_ sent seqnos > * B creates an entry for A with the lowest and highest seqnos > * B sends a {{SYNC-ACK}} to A > * A resets the flag and starts accepting {{STABLE}} / {{ACK}} messages from B again > * A and B now use the usual protocols to retransmit missing messages -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-4) Add the ability to override the specific version of Maven artifacts

by Stuart Douglas (JIRA)

Stuart Douglas created WFBUILD-4: ------------------------------------ Summary: Add the ability to override the specific version of Maven artifacts Key: WFBUILD-4 URL: https://issues.jboss.org/browse/WFBUILD-4 Project: WildFly Build Tools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Stuart Douglas Assignee: Stuart Douglas e.g. it should be possible to assemble a server with a newer version of Weld or Resteasy that what was provided in the feature pack. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-3) Add the ability to install deployments to a provisioned server

by Stuart Douglas (JIRA)

Stuart Douglas created WFBUILD-3: ------------------------------------ Summary: Add the ability to install deployments to a provisioned server Key: WFBUILD-3 URL: https://issues.jboss.org/browse/WFBUILD-3 Project: WildFly Build Tools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Stuart Douglas Assignee: Stuart Douglas It should be possible to resolve and install (from a maven repository) a user deployment, so a fully functional server can be provisioned directly. The option should be provided to either copy to the deployments directory, or to install it directly in the content repository (so this could work with domain mode as well). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-2) Implement feature pack filtering

by Stuart Douglas (JIRA)

Stuart Douglas created WFBUILD-2: ------------------------------------ Summary: Implement feature pack filtering Key: WFBUILD-2 URL: https://issues.jboss.org/browse/WFBUILD-2 Project: WildFly Build Tools Issue Type: Task Security Level: Public (Everyone can see) Reporter: Stuart Douglas Assignee: Stuart Douglas It should be possible to provision a server with only a subset of the modules required by a feature pack. For instance a user may wish to take the wildfly-web feature pack, and then add just the JPA component of the full server. It should be possible to specify this in the provisioning file, and all transient dependencies should also be included. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-1) Create command line tool to run provisioning tasks

by Stuart Douglas (JIRA)

Stuart Douglas created WFBUILD-1: ------------------------------------ Summary: Create command line tool to run provisioning tasks Key: WFBUILD-1 URL: https://issues.jboss.org/browse/WFBUILD-1 Project: WildFly Build Tools Issue Type: Task Security Level: Public (Everyone can see) Reporter: Stuart Douglas Assignee: Stuart Douglas It should be possible to provision a Wildfly server from the command line, so to this end we need a command line wrapper around the provisioning library (complete with Windows/Linux wrapper scripts). It does not make sense to include this in the WF CLI in my opinion, as the CLI is only available if you have already provisioned a server. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3800) Upgrade weld-core-impl to 2.2.4.Final

by Juergen Zimmermann (JIRA)

Juergen Zimmermann created WFLY-3800: ---------------------------------------- Summary: Upgrade weld-core-impl to 2.2.4.Final Key: WFLY-3800 URL: https://issues.jboss.org/browse/WFLY-3800 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: CDI / Weld Affects Versions: 9.0.0.Beta1 Reporter: Juergen Zimmermann Assignee: Stuart Douglas weld-core-impl is available in version 2.2.4.Final since July 18. Could you update the property version.org.jboss.weld.weld in pom.xml to 2.2.4.Final? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3799) Wrong WildFly version when WildFly standalone is started

by Juergen Zimmermann (JIRA)

Juergen Zimmermann created WFLY-3799: ---------------------------------------- Summary: Wrong WildFly version when WildFly standalone is started Key: WFLY-3799 URL: https://issues.jboss.org/browse/WFLY-3799 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: ConfigAdmin Affects Versions: 9.0.0.Beta1 Reporter: Juergen Zimmermann Assignee: Thomas Diesler I compiled the WildFly snapshot from GitHub. When I start WildFly standalone, then I see this final log message with the version number from WildFly Core: {code} INFO [org.jboss.as] WFLYSRV0025: WildFly 1.0.0.Alpha5 "Kenny" started in 2454ms - Started 216 of 319 services (143 services are lazy, passive or on-demand) {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 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 September 2014