March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6630) Unable to change attributes of Mail session through cli

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6630?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6630: ---------------------------------------------- Jakub Cechacek <jcechace(a)redhat.com> changed the Status of [bug 910282|https://bugzilla.redhat.com/show_bug.cgi?id=910282] from VERIFIED to ASSIGNED > Unable to change attributes of Mail session through cli > ------------------------------------------------------- > > Key: AS7-6630 > URL: https://issues.jboss.org/browse/AS7-6630 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management, Mail > Affects Versions: 7.2.0.Alpha1, 8.0.0.Alpha1 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 7.3.0.Alpha1, 8.0.0.Alpha1 > > > Any attempt to change Mail session after it was created fails > Steps to Reproduce: In jboss-cli > 1. Create new session > /subsystem=mail/mail-session=mysession/:add(jndi-name="java:/musession") > result: > {"outcome" => "success"} > 2. Check created resource > /subsystem=mail/mail-session=mysession/:read-resource > result: > { > "outcome" => "success", > "result" => { > "custom" => undefined, > "debug" => false, > "from" => undefined, > "jndi-name" => "java:/mysession", > "server" => undefined > } > } > 3. Try to change some attribute (e.g. jndi) > /subsystem=mail/mail-session=mysession/:write-attribute(name=jndi-name,value="java:/mailsession") > result: > { > "outcome" => "failed", > "failure-description" => "JBAS014749: Operation handler failed: null", > "rolled-back" => true > } > > expected result: > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > Additional: > The debug attribute can be changed exactly once and only to true. Once it is turned on it cannot be changed again like the rest. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6630) Unable to change attributes of Mail session through cli

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6630?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6630: ---------------------------------------------- Jakub Cechacek <jcechace(a)redhat.com> made a comment on [bug 910282|https://bugzilla.redhat.com/show_bug.cgi?id=910282] Sorry my mistake, this is still not verified. For 6.1.ER1 operation still results in ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014612: Operation ("write-attribute") failed - address: ([ ("subsystem" => "mail"), ("mail-session" => "mysession") ]): java.lang.NullPointerException http://pastebin.test.redhat.com/130820 > Unable to change attributes of Mail session through cli > ------------------------------------------------------- > > Key: AS7-6630 > URL: https://issues.jboss.org/browse/AS7-6630 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management, Mail > Affects Versions: 7.2.0.Alpha1, 8.0.0.Alpha1 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 7.3.0.Alpha1, 8.0.0.Alpha1 > > > Any attempt to change Mail session after it was created fails > Steps to Reproduce: In jboss-cli > 1. Create new session > /subsystem=mail/mail-session=mysession/:add(jndi-name="java:/musession") > result: > {"outcome" => "success"} > 2. Check created resource > /subsystem=mail/mail-session=mysession/:read-resource > result: > { > "outcome" => "success", > "result" => { > "custom" => undefined, > "debug" => false, > "from" => undefined, > "jndi-name" => "java:/mysession", > "server" => undefined > } > } > 3. Try to change some attribute (e.g. jndi) > /subsystem=mail/mail-session=mysession/:write-attribute(name=jndi-name,value="java:/mailsession") > result: > { > "outcome" => "failed", > "failure-description" => "JBAS014749: Operation handler failed: null", > "rolled-back" => true > } > > expected result: > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > Additional: > The debug attribute can be changed exactly once and only to true. Once it is turned on it cannot be changed again like the rest. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6630) Unable to change attributes of Mail session through cli

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6630?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6630: ---------------------------------------------- Jakub Cechacek <jcechace(a)redhat.com> made a comment on [bug 910282|https://bugzilla.redhat.com/show_bug.cgi?id=910282] Verified 6.1.ER1 > Unable to change attributes of Mail session through cli > ------------------------------------------------------- > > Key: AS7-6630 > URL: https://issues.jboss.org/browse/AS7-6630 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management, Mail > Affects Versions: 7.2.0.Alpha1, 8.0.0.Alpha1 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 7.3.0.Alpha1, 8.0.0.Alpha1 > > > Any attempt to change Mail session after it was created fails > Steps to Reproduce: In jboss-cli > 1. Create new session > /subsystem=mail/mail-session=mysession/:add(jndi-name="java:/musession") > result: > {"outcome" => "success"} > 2. Check created resource > /subsystem=mail/mail-session=mysession/:read-resource > result: > { > "outcome" => "success", > "result" => { > "custom" => undefined, > "debug" => false, > "from" => undefined, > "jndi-name" => "java:/mysession", > "server" => undefined > } > } > 3. Try to change some attribute (e.g. jndi) > /subsystem=mail/mail-session=mysession/:write-attribute(name=jndi-name,value="java:/mailsession") > result: > { > "outcome" => "failed", > "failure-description" => "JBAS014749: Operation handler failed: null", > "rolled-back" => true > } > > expected result: > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > Additional: > The debug attribute can be changed exactly once and only to true. Once it is turned on it cannot be changed again like the rest. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (AS7-6630) Unable to change attributes of Mail session through cli

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6630?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6630: ---------------------------------------------- Jakub Cechacek <jcechace(a)redhat.com> changed the Status of [bug 910282|https://bugzilla.redhat.com/show_bug.cgi?id=910282] from ON_QA to VERIFIED > Unable to change attributes of Mail session through cli > ------------------------------------------------------- > > Key: AS7-6630 > URL: https://issues.jboss.org/browse/AS7-6630 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management, Mail > Affects Versions: 7.2.0.Alpha1, 8.0.0.Alpha1 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 7.3.0.Alpha1, 8.0.0.Alpha1 > > > Any attempt to change Mail session after it was created fails > Steps to Reproduce: In jboss-cli > 1. Create new session > /subsystem=mail/mail-session=mysession/:add(jndi-name="java:/musession") > result: > {"outcome" => "success"} > 2. Check created resource > /subsystem=mail/mail-session=mysession/:read-resource > result: > { > "outcome" => "success", > "result" => { > "custom" => undefined, > "debug" => false, > "from" => undefined, > "jndi-name" => "java:/mysession", > "server" => undefined > } > } > 3. Try to change some attribute (e.g. jndi) > /subsystem=mail/mail-session=mysession/:write-attribute(name=jndi-name,value="java:/mailsession") > result: > { > "outcome" => "failed", > "failure-description" => "JBAS014749: Operation handler failed: null", > "rolled-back" => true > } > > expected result: > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > Additional: > The debug attribute can be changed exactly once and only to true. Once it is turned on it cannot be changed again like the rest. -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1600) Deadlock in Infinispan with TCP and use_send_queues=true

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1600?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1600. ---------------------------- Resolution: Deferred There's a workaround, until 3.3 is in place > Deadlock in Infinispan with TCP and use_send_queues=true > -------------------------------------------------------- > > Key: JGRP-1600 > URL: https://issues.jboss.org/browse/JGRP-1600 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > https://issues.jboss.org/browse/ISPN-2836 -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1600) Deadlock in Infinispan with TCP and use_send_queues=true

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1600?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1600: -------------------------------- It looks like https://issues.jboss.org/browse/JGRP-1549 fixed the original issue (sender threads waiting on the send-queue, but consumer de-queuing from a different send-queue). I'm therefore going to close https://issues.jboss.org/browse/JGRP-1600. The workaround is to set use_send_queues to false, until 3.3 is released. I don't want to backport JGRP-1549 as this involves too many changes. Feel free to reopen JGRP-1600 if this is still a JGroups issue. > Deadlock in Infinispan with TCP and use_send_queues=true > -------------------------------------------------------- > > Key: JGRP-1600 > URL: https://issues.jboss.org/browse/JGRP-1600 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > https://issues.jboss.org/browse/ISPN-2836 -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1084?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1084: --------------------------- Fix Version/s: 3.3 (was: Future) I think this issue has been resolved at the CommandAwareRpcDispatcher level, please reopen if this isn't the case > MessageDispatched to have marshalling callback after real_dest have been calculated > ----------------------------------------------------------------------------------- > > Key: JGRP-1084 > URL: https://issues.jboss.org/browse/JGRP-1084 > Project: JGroups > Issue Type: Feature Request > Reporter: Galder Zamarreño > Assignee: Vladimir Blagojevic > Priority: Minor > Fix For: 3.3 > > > A week ago filled I ISPN-237 jira in order for dist commands that should only affect the local machine not to go remove. While investigating your stress test, I've found out that JGroups' MessageDispatcher.castMessage already does that! > if(tmp != null && > tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) { > if(local_addr == null) { > local_addr=tmp.getAddress(); > } > if(local_addr != null) { > real_dests.removeElement(local_addr); > } > } > That code empties the real_dests if the target is the local address. So, you're probably wondering why I filled ISPN-237? It's because marshalling happens before the code above gets executed. In fact, it happens at the beginning of ReplicationTask.call() and the JGroups optimization happens when castMessage() is called from ReplicationTask.call(). > So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call should stay local, so ISPN should need to do this calculation again, it's wasteful code. The real fix would be to somehow be able to do marshalling only if the code in MessageDispatcher.castMessage() said that real_dests was not empty. > Bela, do you think JGroups could be enhanced to have a callback after the code shown above where we can invoke marshalling? -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1084?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1084. ---------------------------- Resolution: Won't Fix > MessageDispatched to have marshalling callback after real_dest have been calculated > ----------------------------------------------------------------------------------- > > Key: JGRP-1084 > URL: https://issues.jboss.org/browse/JGRP-1084 > Project: JGroups > Issue Type: Feature Request > Reporter: Galder Zamarreño > Assignee: Vladimir Blagojevic > Priority: Minor > Fix For: 3.3 > > > A week ago filled I ISPN-237 jira in order for dist commands that should only affect the local machine not to go remove. While investigating your stress test, I've found out that JGroups' MessageDispatcher.castMessage already does that! > if(tmp != null && > tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) { > if(local_addr == null) { > local_addr=tmp.getAddress(); > } > if(local_addr != null) { > real_dests.removeElement(local_addr); > } > } > That code empties the real_dests if the target is the local address. So, you're probably wondering why I filled ISPN-237? It's because marshalling happens before the code above gets executed. In fact, it happens at the beginning of ReplicationTask.call() and the JGroups optimization happens when castMessage() is called from ReplicationTask.call(). > So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call should stay local, so ISPN should need to do this calculation again, it's wasteful code. The real fix would be to somehow be able to do marshalling only if the code in MessageDispatcher.castMessage() said that real_dests was not empty. > Bela, do you think JGroups could be enhanced to have a callback after the code shown above where we can invoke marshalling? -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1105) UNICAST: don't send retransmission messages individually

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1105?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1105: --------------------------- Fix Version/s: 3.3 (was: Future) > UNICAST: don't send retransmission messages individually > -------------------------------------------------------- > > Key: JGRP-1105 > URL: https://issues.jboss.org/browse/JGRP-1105 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > Essentially the same as for NAKACK: instead of adding every message to the retransmitter and creating 1 timer task for it, we create SeqnoRanges in increments of (say) 1000 messages. SeqnoRange #1 is 1-1000, #2 is 1001-2000 and so on. > Every SeqnoRange has a low and a high, e.g. lo=1 and high=1000. However, we only retransmit messages with their bit set to 0 from low to bits.length: if we added messages 1-100 to the first range, then low=1, length=100 and high=1000. We only retransmit from 1-100. > This creates 1 task in the timer for 1000 messages, instead of 1000 tasks ! When adding a new message (e.g. 101), length() gets automatically adjusted, so retransmission will include 1-101 (only the 0 bits of course). -- 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1105) UNICAST: don't send retransmission messages individually

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1105?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1105. ---------------------------- Resolution: Won't Fix > UNICAST: don't send retransmission messages individually > -------------------------------------------------------- > > Key: JGRP-1105 > URL: https://issues.jboss.org/browse/JGRP-1105 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.3 > > > Essentially the same as for NAKACK: instead of adding every message to the retransmitter and creating 1 timer task for it, we create SeqnoRanges in increments of (say) 1000 messages. SeqnoRange #1 is 1-1000, #2 is 1001-2000 and so on. > Every SeqnoRange has a low and a high, e.g. lo=1 and high=1000. However, we only retransmit messages with their bit set to 0 from low to bits.length: if we added messages 1-100 to the first range, then low=1, length=100 and high=1000. We only retransmit from 1-100. > This creates 1 task in the timer for 1000 messages, instead of 1000 tasks ! When adding a new message (e.g. 101), length() gets automatically adjusted, so retransmission will include 1-101 (only the 0 bits of course). -- 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

13 years, 4 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 March 2013