October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the thread waiting

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1711: --------------------------- Fix Version/s: 3.4 Radim, I'm busy with 2 other issues. If you submit a pull request by Friday morning, I can get your fix into 3.4, otherwise I'll push it into 3.5. > DELAY2: Do not keep the thread waiting > -------------------------------------- > > Key: JGRP-1711 > URL: https://issues.jboss.org/browse/JGRP-1711 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.4 > Reporter: Radim Vansa > Assignee: Bela Ban > Priority: Minor > Fix For: 3.4 > > > Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period. > As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period. > For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers. > Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the thread waiting

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1711: -------------------------------- I think the reason was that with loopback, messages are copied and sent back up. But you're right: this is done above the transport so the above is moot. > DELAY2: Do not keep the thread waiting > -------------------------------------- > > Key: JGRP-1711 > URL: https://issues.jboss.org/browse/JGRP-1711 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.4 > Reporter: Radim Vansa > Assignee: Bela Ban > Priority: Minor > > Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period. > As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period. > For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers. > Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the thread waiting

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-1711?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on JGRP-1711: ----------------------------------- As the implementation of incoming messages delay would be more complicated, I think that implementing outcoming delay could be sufficient. Anyway, I can't distinguish where the message got delayed on network. What was the reason to provide both delays in DELAY? > DELAY2: Do not keep the thread waiting > -------------------------------------- > > Key: JGRP-1711 > URL: https://issues.jboss.org/browse/JGRP-1711 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.4 > Reporter: Radim Vansa > Assignee: Bela Ban > Priority: Minor > > Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period. > As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period. > For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers. > Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1711) DELAY2: Do not keep the thread waiting

by Radim Vansa (JIRA)

Radim Vansa created JGRP-1711: --------------------------------- Summary: DELAY2: Do not keep the thread waiting Key: JGRP-1711 URL: https://issues.jboss.org/browse/JGRP-1711 Project: JGroups Issue Type: Feature Request Affects Versions: 3.4 Reporter: Radim Vansa Assignee: Bela Ban Priority: Minor Current version of the DELAY protocol is rather simplistic - the thread is just put to sleep for some period of time. However, this does not reflect the network delay very well as it consumes the thread during the latency period. As the protocol should be usually placed just above TP, I'd suggest that for outcoming delay, the message/event should be placed into priority queue and another dedicated thread should pass it down after the latency period. For the incoming messages, we'd probably need a way to access TP's threadpools, and to find out where the currently executing thread belongs. Then, the message/event would also use priority queue and take a thread from the same threadpool in order to deliver it to upper layers. Another feature of this new implementation of delay protocol would be to allow constant latency, or rather specify the latency interval (from - to: currently from is always 0). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2193) Upgrade javax.json to version 1.0.3

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/WFLY-2193?page=com.atlassian.jira.plugin.... ] Shelly McGowan updated WFLY-2193: --------------------------------- Issue Type: Component Upgrade (was: Feature Request) > Upgrade javax.json to version 1.0.3 > ----------------------------------- > > Key: WFLY-2193 > URL: https://issues.jboss.org/browse/WFLY-2193 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Shelly McGowan > Assignee: Shelly McGowan > Fix For: 8.0.0.CR1 > > > WildFly consumes org.glassfish:javax.json artifacts, version 1.0. This needs to be updated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1913) CLI 'module add' command fail if a drive letter is specified in its resource path

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.... ] Ivo Studensky edited comment on WFLY-1913 at 10/1/13 10:02 AM: --------------------------------------------------------------- Ah, nevermind, too many context switches on my side. It needs a module add command included in the deploy.scr script. I will enhance the test case accordingly and fix the issue. was (Author: istudens): Ah, nevermind. It needs a module add command included in the deploy.scr script. I will enhance the test case accordingly and fix the issue. > CLI 'module add' command fail if a drive letter is specified in its resource path > --------------------------------------------------------------------------------- > > Key: WFLY-1913 > URL: https://issues.jboss.org/browse/WFLY-1913 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 8.0.0.Alpha4 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 8.0.0.Beta1 > > Attachments: install-mojarra-2.0.0.cli > > > If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2193) Upgrade javax.json to version 1.0.3

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/WFLY-2193?page=com.atlassian.jira.plugin.... ] Shelly McGowan updated WFLY-2193: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/5187 > Upgrade javax.json to version 1.0.3 > ----------------------------------- > > Key: WFLY-2193 > URL: https://issues.jboss.org/browse/WFLY-2193 > Project: WildFly > Issue Type: Feature Request > Reporter: Shelly McGowan > Assignee: Shelly McGowan > Fix For: 8.0.0.CR1 > > > WildFly consumes org.glassfish:javax.json artifacts, version 1.0. This needs to be updated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2156) Upgrade scannotation to 1.0.3

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2156?page=com.atlassian.jira.plugin.... ] Stuart Douglas updated WFLY-2156: --------------------------------- Assignee: Weinan Li (was: Stuart Douglas) > Upgrade scannotation to 1.0.3 > ----------------------------- > > Key: WFLY-2156 > URL: https://issues.jboss.org/browse/WFLY-2156 > Project: WildFly > Issue Type: Feature Request > Components: REST > Affects Versions: 8.0.0.Alpha4 > Reporter: Weinan Li > Assignee: Weinan Li > > RESTEasy has a dependency on 1.0.3 of scannotation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2181) TempFileProviderService creates a static, non-daemon thread pool

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-2181. ---------------------------------- Fix Version/s: 8.0.0.Beta1 Resolution: Done > TempFileProviderService creates a static, non-daemon thread pool > ---------------------------------------------------------------- > > Key: WFLY-2181 > URL: https://issues.jboss.org/browse/WFLY-2181 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 8.0.0.Alpha4 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 8.0.0.Beta1 > > > This can prevent the server from shutting down -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1913) CLI 'module add' command fail if a drive letter is specified in its resource path

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.... ] Ivo Studensky commented on WFLY-1913: ------------------------------------- Ah, nevermind. It needs a module add command included in the deploy.scr script. I will enhance the test case accordingly and fix the issue. > CLI 'module add' command fail if a drive letter is specified in its resource path > --------------------------------------------------------------------------------- > > Key: WFLY-1913 > URL: https://issues.jboss.org/browse/WFLY-1913 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 8.0.0.Alpha4 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > Fix For: 8.0.0.Beta1 > > Attachments: install-mojarra-2.0.0.cli > > > If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 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 2013