[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:
----------------------------------------------
Tomaz Cerar <tcerar(a)redhat.com> made a comment on [bug 910282|https://bugzilla.redhat.com/show_bug.cgi?id=910282]
> 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, 6 months
[JBoss JIRA] (JGRP-1604) SEQUENCER problems and slowness
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1604?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1604.
----------------------------
Resolution: Done
> SEQUENCER problems and slowness
> -------------------------------
>
> Key: JGRP-1604
> URL: https://issues.jboss.org/browse/JGRP-1604
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> On high volumes of messages (e.g. MPerf), SEQUENCER runs out of memory.
> The culprit is the forward-table, which is unbounded, and if messages are added as a faster rate than the time it takes to forward the message to the coordinator (sequencer) and for it to be received as a multicast and subsequently be removed from the forward-table, memory increases.
> This also makes SEQUENCER slow.
> SOLUTION:
> * Look into bounding the forward-table, e.g. define the max number of bytes to be in the table at any given time
> * When a message is to be added, its length is checked (Message.getLength())
> ** If the length is 0 or length + accumulated bytes is less than max: add, else block
> * A received message (sent by self) causes the entry to be removed from the forward-table and its length to be subtracted from accumulated bytes (unblocking potentially blocked threads)
> We should also look at delivery table and see if we can make it simpler, e.g. by running a gathering round when a new sequencer is chosen, determining the highest seqnos of all members
--
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, 6 months
[JBoss JIRA] (AS7-6663) Usability issue: 'Reload' operation in CLI returns information that another reload is required
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6663?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6663:
----------------------------------------------
Jan Martiska <jmartisk(a)redhat.com> made a comment on [bug 900210|https://bugzilla.redhat.com/show_bug.cgi?id=900210]
Tried with EAP 6.1.0.ER1 and couldn't reproduce it anymore either. It seems someone might have already fixed that. So let's close it :)
> Usability issue: 'Reload' operation in CLI returns information that another reload is required
> ----------------------------------------------------------------------------------------------
>
> Key: AS7-6663
> URL: https://issues.jboss.org/browse/AS7-6663
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP), 7.2.0.Alpha1
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
> Fix For: 8.0.0.Alpha1
>
>
> Jan Martiska reported:
> Assume a server reload is required.. then you do this:
> {code}
> [standalone@localhost:9999 /] :reload
> {
> "outcome" => "success",
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> I think it is quite confusing that "reload-required" is returned from 'reload' operation. (if you do more operations, it will not appear again, only once). Is it possible to fix it?
--
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, 6 months