[JBoss JIRA] (WFLY-2523) cygwin jboss-cli.sh
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-2523?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky resolved WFLY-2523.
-------------------------------------
Fix Version/s: 8.0.0.Final
Resolution: Done
Merged into master.
> cygwin jboss-cli.sh
> -------------------
>
> Key: WFLY-2523
> URL: https://issues.jboss.org/browse/WFLY-2523
> Project: WildFly
> Issue Type: Patch
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.0.0.Beta1
> Environment: windows 7 x64 / cygwin
> Reporter: Darko Palic
> Assignee: Alexey Loubyansky
> Labels: cli, cygwin
> Fix For: 8.0.0.Final
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> On cygwin is the implementation of the path variables not correct in the script jboss-cli.sh. Right now under cygwin the paths get mixed in POSIX and Windows style. The module path (-mp param) is in POSIX style and the rest of the command is in windows style. So the startup of the org.jboss.as.cli ends up with
> {code}
> org.jboss.modules.ModuleNotFoundException: org.jboss.as.cli:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240)
> at org.jboss.modules.Main.main(Main.java:385)
> {code}
> Right now wildfly 8 beta1 has following implementation:
> {code:title=jboss-cli.sh|borderStyle=solid}
> # For Cygwin, switch paths to Windows format before running java
> if $cygwin; then
> JBOSS_HOME=`cygpath --path --windows "$JBOSS_HOME"`
> JAVA_HOME=`cygpath --path --windows "$JAVA_HOME"`
> fi
> {code}
> and it should be:
> {code:title=jboss-cli.sh|borderStyle=solid}
> # For Cygwin, switch paths to Windows format before running java
> if $cygwin; then
> JBOSS_HOME=`cygpath --path --windows "$JBOSS_HOME"`
> JAVA_HOME=`cygpath --path --windows "$JAVA_HOME"`
> JBOSS_MODULEPATH=`cygpath --path --windows "$JBOSS_MODULEPATH"`
> fi
> {code}
> PS: I searched for similar cli issues in the issue tracker, but couldn't find any issue.
--
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, 6 months
[JBoss JIRA] (JGRP-1769) Table.add() with message list can lead to many resizings
by Bela Ban (JIRA)
Bela Ban created JGRP-1769:
------------------------------
Summary: Table.add() with message list can lead to many resizings
Key: JGRP-1769
URL: https://issues.jboss.org/browse/JGRP-1769
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 3.5
Table maintains an array of arrays (a matrix) and needs to resize it when adding messages that would go beyond the capacity of the array.
This is done when adding a message.
However, when adding a *list of messages*, as we're adding messages individually, we compute the needed capacity and perform a resize if needed.
This leads to possibly too much copying.
SOLUTION:
* When adding a list of messages, do the resizing (if needed) *before* adding messages individually
--
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, 6 months
[JBoss JIRA] (JGRP-1768) NAKACK2: processing of OOB messages and message batches
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1768?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1768:
---------------------------
Description: See if the ideas detailed in JGRP-1767 can be applied to NAKACK2 (was: Currently, when OOB message batches are received, the following happens:
* All messages from the batch are added to the table
* We iterate through the batch and remove those message whose {{OOB_DELIVERED}} flag cannot be set (already processed and delivered by a different thread).
* The batch is passed up
* Then we try to remove as many messages from the table as possible and pass them up (as a batch again)
** Messages whose {{OOB_DELIVERED}} flag is set, are discarded
This is a lot of work and we're accessing the table more than needed for OOB batches. A few things can be changed to make this more efficient:
* The thread which processes a message ot message batch will deliver the message to the application if the message or batch hasn't been delivered yet
** Batch
*** we only add those messages from list L to table T if they haven't yet been added
*** Messages from L which couldn't be added to T are removed from L
*** All messages from L are added to a new batch and that batch is then passed up (delivered)
** Single message
*** If the message was added successfuly, we deliver it, else we drop it
* When removing messages from the table ({{Table.removeMany()}}), we skip OOB messages. This is done with a new Table.add() method (including a filter)
* Further optimization: when adding an OOB message to T, we add a reference to a static OOB message, so *all OOB messages in a table point to the same instance !* Since we skip OOB messages when removing messages, this doesn't matter. However, this reduces the memory needed by Table if there are many OOB messages)
> NAKACK2: processing of OOB messages and message batches
> -------------------------------------------------------
>
> Key: JGRP-1768
> URL: https://issues.jboss.org/browse/JGRP-1768
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> See if the ideas detailed in JGRP-1767 can be applied to NAKACK2
--
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, 6 months
[JBoss JIRA] (JGRP-1768) NAKACK2: processing of OOB messages and message batches
by Bela Ban (JIRA)
Bela Ban created JGRP-1768:
------------------------------
Summary: NAKACK2: processing of OOB messages and message batches
Key: JGRP-1768
URL: https://issues.jboss.org/browse/JGRP-1768
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
Currently, when OOB message batches are received, the following happens:
* All messages from the batch are added to the table
* We iterate through the batch and remove those message whose {{OOB_DELIVERED}} flag cannot be set (already processed and delivered by a different thread).
* The batch is passed up
* Then we try to remove as many messages from the table as possible and pass them up (as a batch again)
** Messages whose {{OOB_DELIVERED}} flag is set, are discarded
This is a lot of work and we're accessing the table more than needed for OOB batches. A few things can be changed to make this more efficient:
* The thread which processes a message ot message batch will deliver the message to the application if the message or batch hasn't been delivered yet
** Batch
*** we only add those messages from list L to table T if they haven't yet been added
*** Messages from L which couldn't be added to T are removed from L
*** All messages from L are added to a new batch and that batch is then passed up (delivered)
** Single message
*** If the message was added successfuly, we deliver it, else we drop it
* When removing messages from the table ({{Table.removeMany()}}), we skip OOB messages. This is done with a new Table.add() method (including a filter)
* Further optimization: when adding an OOB message to T, we add a reference to a static OOB message, so *all OOB messages in a table point to the same instance !* Since we skip OOB messages when removing messages, this doesn't matter. However, this reduces the memory needed by Table if there are many OOB messages
--
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, 6 months
[JBoss JIRA] (JGRP-1767) UNICAST3: processing of OOB messages and message batches
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1767?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1767 at 1/9/14 6:15 AM:
--------------------------------------------------------
In other words, for OOB messages, we only use Table as a means to keep track of which seqnos have been delivered, to prevent duplicate delivery. We're not interested in the messages themselves, as they've been delivered by the processing thread from the OOB thread pool.
was (Author: belaban):
In a nutshell, for OOB messages, we only use Table as a means to keep track of which seqnos have been delivered, to prevent duplicate delivery. We're not interested in the messages themselves, as they've been delivered by the processing thread from the OOB thread pool.
> UNICAST3: processing of OOB messages and message batches
> --------------------------------------------------------
>
> Key: JGRP-1767
> URL: https://issues.jboss.org/browse/JGRP-1767
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, when OOB message batches are received, the following happens:
> * All messages from the batch are added to the table
> * We iterate through the batch and remove those message whose {{OOB_DELIVERED}} flag cannot be set (already processed and delivered by a different thread).
> * The batch is passed up
> * Then we try to remove as many messages from the table as possible and pass them up (as a batch again)
> ** Messages whose {{OOB_DELIVERED}} flag is set, are discarded
> This is a lot of work and we're accessing the table more than needed for OOB batches. A few things can be changed to make this more efficient:
> * The thread which processes a message ot message batch will deliver the message to the application if the message or batch hasn't been delivered yet
> ** Batch
> *** we only add those messages from list L to table T if they haven't yet been added
> *** Messages from L which couldn't be added to T are removed from L
> *** All messages from L are added to a new batch and that batch is then passed up (delivered)
> ** Single message
> *** If the message was added successfuly, we deliver it, else we drop it
> * When removing messages from the table ({{Table.removeMany()}}), we skip OOB messages. This is done with a new Table.add() method (including a filter)
> * Further optimization: when adding an OOB message to T, we add a reference to a static OOB message, so *all OOB messages in a table point to the same instance !* Since we skip OOB messages when removing messages, this doesn't matter. However, this reduces the memory needed by Table if there are many OOB messages
--
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, 6 months
[JBoss JIRA] (JGRP-1767) UNICAST3: processing of OOB messages and message batches
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1767?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1767:
--------------------------------
In a nutshell, for OOB messages, we only use Table as a means to keep track of which seqnos have been delivered, to prevent duplicate delivery. We're not interested in the messages themselves, as they've been delivered by the processing thread from the OOB thread pool.
> UNICAST3: processing of OOB messages and message batches
> --------------------------------------------------------
>
> Key: JGRP-1767
> URL: https://issues.jboss.org/browse/JGRP-1767
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Currently, when OOB message batches are received, the following happens:
> * All messages from the batch are added to the table
> * We iterate through the batch and remove those message whose {{OOB_DELIVERED}} flag cannot be set (already processed and delivered by a different thread).
> * The batch is passed up
> * Then we try to remove as many messages from the table as possible and pass them up (as a batch again)
> ** Messages whose {{OOB_DELIVERED}} flag is set, are discarded
> This is a lot of work and we're accessing the table more than needed for OOB batches. A few things can be changed to make this more efficient:
> * The thread which processes a message ot message batch will deliver the message to the application if the message or batch hasn't been delivered yet
> ** Batch
> *** we only add those messages from list L to table T if they haven't yet been added
> *** Messages from L which couldn't be added to T are removed from L
> *** All messages from L are added to a new batch and that batch is then passed up (delivered)
> ** Single message
> *** If the message was added successfuly, we deliver it, else we drop it
> * When removing messages from the table ({{Table.removeMany()}}), we skip OOB messages. This is done with a new Table.add() method (including a filter)
> * Further optimization: when adding an OOB message to T, we add a reference to a static OOB message, so *all OOB messages in a table point to the same instance !* Since we skip OOB messages when removing messages, this doesn't matter. However, this reduces the memory needed by Table if there are many OOB messages
--
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, 6 months