October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1714) Headers: data in some headers might be too large in big clusters

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1714?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1714 at 10/4/13 7:43 AM: --------------------------------------------------------- * {{PingHeader}}: DONE * {{FD_SOCK.FdHeader}}: DONE * {{STABLE.StableHeader}}: DONE * {{FLUSH.FlushHeader}}: DONE was (Author: belaban): * {{PingHeader}}: DONE * {{FD_SOCK.FdHeader}}: DONE * {{STABLE.StableHeader}}: DONE > Headers: data in some headers might be too large in big clusters > ---------------------------------------------------------------- > > Key: JGRP-1714 > URL: https://issues.jboss.org/browse/JGRP-1714 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4 > > > Similar to JGRP-1710 and JGRP-1713, investigate headers which might become too big, and move their contents into the message body. Check all headers which contain > * a view > * a digest > * a list of members > Candidates: > * {{PingHeader}}. > Probable solution: move {{PingHeader.PingData}} from the header to the message body -- 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, 9 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 updated JGRP-1711: --------------------------- Fix Version/s: 3.5 (was: 3.4) > 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.5 > > > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-285) JtaTransactionSynchronizationAdapter contains infite loop

by Nils Miehe (JIRA)

Nils Miehe created DROOLS-285: --------------------------------- Summary: JtaTransactionSynchronizationAdapter contains infite loop Key: DROOLS-285 URL: https://issues.jboss.org/browse/DROOLS-285 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.5.0.Final Reporter: Nils Miehe Assignee: Mark Proctor Fix For: 6.0.0.CR5 I stumbled upon this while searching for a potential cause of JBPM-4132 . In the method afterCompletion of JtaTransactionSynchronizationAdapter a call with STATUS_ACTIVE would cause an infinite loop. As this value in itself indicates an inconsistent state the error probably wasn't noticed earlier. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2215) WorkManagerService does not start work manager

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created WFLY-2215: ---------------------------------------- Summary: WorkManagerService does not start work manager Key: WFLY-2215 URL: https://issues.jboss.org/browse/WFLY-2215 Project: WildFly Issue Type: Enhancement Components: JCA Affects Versions: 8.0.0.Beta1 Reporter: Bartosz Baranowski Assignee: Stefano Maestri Fix For: 8.0.0.Beta1 WorkManagerService does not start/restart WorkManager https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/or... WorkManager is set in constructor. In stop method, WorkManager.shutdown() is called. start() should invoke WorkManager.cancelShutdown(). -- 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, 9 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2181: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> made a comment on [bug 1012968|https://bugzilla.redhat.com/show_bug.cgi?id=1012968] Verified on EAP 6.2.0.ER4 > 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, 9 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2181: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1012968|https://bugzilla.redhat.com/show_bug.cgi?id=1012968] from ON_QA to VERIFIED > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-327) Remote JNDI is not working with a HornetQ-only JMS bridge

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-327?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-327: ---------------------------------------------- Martin Svehla <msvehla(a)redhat.com> made a comment on [bug 912653|https://bugzilla.redhat.com/show_bug.cgi?id=912653] No NotSerializableExceptions anymore. Good job. > Remote JNDI is not working with a HornetQ-only JMS bridge > --------------------------------------------------------- > > Key: WFLY-327 > URL: https://issues.jboss.org/browse/WFLY-327 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.0.Alpha1 > > > The jms-bridge can be used to bridge a hornetq server to another and should work by specifying to use the org.hornetq.module to load the JMS implementation classes. > However, this fails because this module does not have access to the JBoss remote-naming module that is required to connect to remote JBoss JNDI server. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-327) Remote JNDI is not working with a HornetQ-only JMS bridge

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-327?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-327: ---------------------------------------------- Martin Svehla <msvehla(a)redhat.com> changed the Status of [bug 912653|https://bugzilla.redhat.com/show_bug.cgi?id=912653] from ON_QA to VERIFIED > Remote JNDI is not working with a HornetQ-only JMS bridge > --------------------------------------------------------- > > Key: WFLY-327 > URL: https://issues.jboss.org/browse/WFLY-327 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.0.Alpha1 > > > The jms-bridge can be used to bridge a hornetq server to another and should work by specifying to use the org.hornetq.module to load the JMS implementation classes. > However, this fails because this module does not have access to the JBoss remote-naming module that is required to connect to remote JBoss JNDI server. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller need to check access before attempting to read information

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2139: ----------------------------------------------- Jakub Cechacek <jcechace(a)redhat.com> changed the Status of [bug 1011994|https://bugzilla.redhat.com/show_bug.cgi?id=1011994] from ON_QA to VERIFIED > ProxyStepHandler/Controller need to check access before attempting to read information > -------------------------------------------------------------------------------------- > > Key: WFLY-2139 > URL: https://issues.jboss.org/browse/WFLY-2139 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 8.0.0.Beta1 > > > This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller need to check access before attempting to read information

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2139: ----------------------------------------------- Jakub Cechacek <jcechace(a)redhat.com> made a comment on [bug 1011994|https://bugzilla.redhat.com/show_bug.cgi?id=1011994] Verified for 6.2.0.ER4 Tests previously failing due to this issue passed. After looking at threads through visual vm I consider this fixed. > ProxyStepHandler/Controller need to check access before attempting to read information > -------------------------------------------------------------------------------------- > > Key: WFLY-2139 > URL: https://issues.jboss.org/browse/WFLY-2139 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 8.0.0.Beta1 > > > This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource. -- 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, 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 2013