[JBoss JIRA] (WFLY-3021) LogStoreDefinition exposes a bogus write-attribute handler for its 'type' attribute
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3021?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-3021.
------------------------------------
Fix Version/s: 8.0.1.Final
(was: 9.0.0.CR1)
Resolution: Won't Fix
I forgot; WFLY-3022 is the 9.x part.
> LogStoreDefinition exposes a bogus write-attribute handler for its 'type' attribute
> -----------------------------------------------------------------------------------
>
> Key: WFLY-3021
> URL: https://issues.jboss.org/browse/WFLY-3021
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.0.1.Final
>
>
> The 'type' attribute of LogStoreResource isn't really read-write. Its value is determined by attributes of the parent resource. The OSH for write-attribute is ReloadRequiredWriteAttributeHandler, and when the reload happens whatever value is set will be lost.
> For 8.0.1 I'll have the OSH just log a WARN. The attribute should be made read-only for 9. I could make it read-only for 8.0.1 but I don't want to do a management API bump, introduce transformation etc.
--
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, 2 months
[JBoss JIRA] (WFLY-3021) LogStoreDefinition exposes a bogus write-attribute handler for its 'type' attribute
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3021?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3021:
-----------------------------------
Fix Version/s: 9.0.0.CR1
(was: 8.0.1.Final)
I'm going to skip the WARN part in 8.0.1 and just deal with it in 9.x. Too much hassle to get ExpressionSupportSmokeTestCase to deal with the fact that writing doesn't actually do anything.
> LogStoreDefinition exposes a bogus write-attribute handler for its 'type' attribute
> -----------------------------------------------------------------------------------
>
> Key: WFLY-3021
> URL: https://issues.jboss.org/browse/WFLY-3021
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 9.0.0.CR1
>
>
> The 'type' attribute of LogStoreResource isn't really read-write. Its value is determined by attributes of the parent resource. The OSH for write-attribute is ReloadRequiredWriteAttributeHandler, and when the reload happens whatever value is set will be lost.
> For 8.0.1 I'll have the OSH just log a WARN. The attribute should be made read-only for 9. I could make it read-only for 8.0.1 but I don't want to do a management API bump, introduce transformation etc.
--
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, 2 months
[JBoss JIRA] (WFLY-2455) Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-2455?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-2455:
--------------------------------
Assignee: Gytis Trikleris (was: Tom Jenkinson)
> Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-2455
> URL: https://issues.jboss.org/browse/WFLY-2455
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Beta1
> Reporter: gui borland
> Assignee: Gytis Trikleris
>
> Using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting, i can register a custom recovery manager for arjuna.
> However, the ArjunaRecoveryManagerService class overwrite the recovery configuration mentioned in my jbossts-properties.xml file with a hardcoded list of recovery modules.
> This makes me wonder if/how the hornetq recovery (org.hornetq.jms.server.recovery.HornetQXAResourceRecover) gets registered in wildfly..
--
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, 2 months
[JBoss JIRA] (WFLY-2455) Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-2455?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-2455:
--------------------------------
Issue Type: Enhancement (was: Bug)
> Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-2455
> URL: https://issues.jboss.org/browse/WFLY-2455
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Beta1
> Reporter: gui borland
> Assignee: Tom Jenkinson
>
> Using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting, i can register a custom recovery manager for arjuna.
> However, the ArjunaRecoveryManagerService class overwrite the recovery configuration mentioned in my jbossts-properties.xml file with a hardcoded list of recovery modules.
> This makes me wonder if/how the hornetq recovery (org.hornetq.jms.server.recovery.HornetQXAResourceRecover) gets registered in wildfly..
--
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, 2 months
[JBoss JIRA] (WFLY-3040) Missing modules
by David Cabillic (JIRA)
David Cabillic created WFLY-3040:
------------------------------------
Summary: Missing modules
Key: WFLY-3040
URL: https://issues.jboss.org/browse/WFLY-3040
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: OSGi
Affects Versions: 8.0.0.Final
Environment: Windows 64 bits
Reporter: David Cabillic
Assignee: Thomas Diesler
I listed modules with links to missing ones :
|| module || missing module ||
| org.infinispan.client.hotrod | com.google.protobuf |
| org.jboss.as.aggregate | org.jboss.as.managed-beans |
| org.jboss.genericjms | org.jboss.genericjms.provider |
--
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, 2 months
[JBoss JIRA] (JBVFS-194) Clean the status of testing jars for jboss-vfs
by Ales Justin (JIRA)
[ https://issues.jboss.org/browse/JBVFS-194?page=com.atlassian.jira.plugin.... ]
Ales Justin commented on JBVFS-194:
-----------------------------------
[~goldmann] >> Can they be replaced with something dummy?
They are dummy. We're just testing their structure; .ear with nested jars / wars.
Or what's the issue with them?
> Clean the status of testing jars for jboss-vfs
> ----------------------------------------------
>
> Key: JBVFS-194
> URL: https://issues.jboss.org/browse/JBVFS-194
> Project: JBoss VFS
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Marek Goldmann
> Assignee: Ales Justin
> Priority: Critical
>
> There are some JARs in jboss-vfs test directory. Some of them are dummy jars containing plain text files, but some of them contain class files. As a general rule Fedora doesn't allow to ship binary files. Although we can have exception for jar files containing dummy files because this is required to test jboss-vfs behavior.
> What's the status of following files? Who wrote them and what is the license of those and where is the upstream code?
> ./src/test/resources/vfs/test/spring-ear.ear/lib/spring-beans.jar
> ./src/test/resources/vfs/test/spring-ear.ear/spring-ejb.jar
> Can they be replaced with something dummy?
--
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, 2 months
[JBoss JIRA] (WFLY-2899) Help and error messages in Main classes should be printed raw
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2899?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2899:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1069514|https://bugzilla.redhat.com/show_bug.cgi?id=1069514] from POST to MODIFIED
> Help and error messages in Main classes should be printed raw
> -------------------------------------------------------------
>
> Key: WFLY-2899
> URL: https://issues.jboss.org/browse/WFLY-2899
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
> Fix For: 8.0.1.Final
>
>
> The help in standalone and host-controller main methods gets printed after {{System.out}} and {{System.err}} have been captured by jboss-stdio. This leads the help and errors being printed in a log manager format rather than just the raw text.
> Example output:
> {code}
> [jperkins@jperkins-rh wildfly]$ ./build/target/wildfly-8.0.0.Final-SNAPSHOT/bin/standalone.sh -help
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/jperkins/projects/jboss/as/wildfly/build/target/wildfly-8.0.0.Final-SNAPSHOT
> JAVA: java
> JAVA_OPTS: -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 15:31:43,895 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 15:31:44,918 INFO [stdout] (main)
> 15:31:44,918 INFO [stdout] (main) Usage: standalone.sh [args...]
> 15:31:44,918 INFO [stdout] (main) where args include:
> 15:31:44,918 INFO [stdout] (main) --admin-only Set the server's running type to
> 15:31:44,919 INFO [stdout] (main) ADMIN_ONLY causing it to open
> 15:31:44,919 INFO [stdout] (main) administrative interfaces and accept
> 15:31:44,919 INFO [stdout] (main) management requests but not start other
> 15:31:44,920 INFO [stdout] (main) runtime services or accept end user
> 15:31:44,920 INFO [stdout] (main) requests.
> 15:31:44,920 INFO [stdout] (main)
> 15:31:44,920 INFO [stdout] (main)
> 15:31:44,921 INFO [stdout] (main) -b <value>, -b=<value> Set system property jboss.bind.address
> 15:31:44,921 INFO [stdout] (main) to the given value
> 15:31:44,921 INFO [stdout] (main)
> 15:31:44,921 INFO [stdout] (main)
> 15:31:44,922 INFO [stdout] (main) -b<interface>=<value> Set system property
> 15:31:44,922 INFO [stdout] (main) jboss.bind.address.<interface> to the
> 15:31:44,922 INFO [stdout] (main) given value
> 15:31:44,922 INFO [stdout] (main)
> 15:31:44,923 INFO [stdout] (main)
> 15:31:44,923 INFO [stdout] (main) -c <config>, -c=<config> Name of the server configuration file
> 15:31:44,923 INFO [stdout] (main) to use (default is "standalone.xml")
> 15:31:44,923 INFO [stdout] (main) (Same as --server-config)
> 15:31:44,924 INFO [stdout] (main)
> 15:31:44,924 INFO [stdout] (main)
> 15:31:44,924 INFO [stdout] (main) --debug [<port>] Activate debug mode with an optional
> 15:31:44,924 INFO [stdout] (main) argument to specify the port. Only
> 15:31:44,925 INFO [stdout] (main) works if the launch script supports it.
> 15:31:44,925 INFO [stdout] (main)
> 15:31:44,925 INFO [stdout] (main)
> 15:31:44,925 INFO [stdout] (main) -D<name>[=<value>] Set a system property
> 15:31:44,926 INFO [stdout] (main)
> 15:31:44,926 INFO [stdout] (main)
> 15:31:44,926 INFO [stdout] (main) -h, --help Display this message and exit
> 15:31:44,927 INFO [stdout] (main)
> 15:31:44,927 INFO [stdout] (main)
> 15:31:44,927 INFO [stdout] (main) --read-only-server-config=<config> Name of the server configuration file
> 15:31:44,927 INFO [stdout] (main) to use. This differs from
> 15:31:44,928 INFO [stdout] (main) '--server-config' and '-c' in that the
> 15:31:44,928 INFO [stdout] (main) original file is never overwritten.
> 15:31:44,928 INFO [stdout] (main)
> 15:31:44,928 INFO [stdout] (main)
> 15:31:44,929 INFO [stdout] (main) -P <url>, -P=<url>, Load system properties from the given
> 15:31:44,929 INFO [stdout] (main) --properties=<url> url
> 15:31:44,929 INFO [stdout] (main)
> 15:31:44,929 INFO [stdout] (main)
> 15:31:44,930 INFO [stdout] (main) -S<name>[=<value>] Set a security property
> 15:31:44,930 INFO [stdout] (main)
> 15:31:44,930 INFO [stdout] (main)
> 15:31:44,930 INFO [stdout] (main) --server-config=<config> Name of the server configuration file
> 15:31:44,931 INFO [stdout] (main) to use (default is "standalone.xml")
> 15:31:44,931 INFO [stdout] (main) (Same as -c)
> 15:31:44,931 INFO [stdout] (main)
> 15:31:44,931 INFO [stdout] (main)
> 15:31:44,932 INFO [stdout] (main) -u <value>, -u=<value> Set system property
> 15:31:44,932 INFO [stdout] (main) jboss.default.multicast.address to the
> 15:31:44,932 INFO [stdout] (main) given value
> 15:31:44,933 INFO [stdout] (main)
> 15:31:44,933 INFO [stdout] (main)
> 15:31:44,933 INFO [stdout] (main) -v, -V, --version Print version and exit
> 15:31:44,934 INFO [stdout] (main)
> 15:31:44,934 INFO [stdout] (main)
> {code}
--
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, 2 months
[JBoss JIRA] (JGRP-1722) Improve performance of ENCRYPT protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1722?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1722:
--------------------------------
As every message that needs to be encrypted (when sent or received) has to acquire the *single* lock in {{ENCRYPT}}, even unrelated messages (e.g. from different senders or tagged as {{OOB|DONT_BUNDLE}}) are delivered or sent sequentially.
SOLUTION: use a pool of ciphers. Each cipher has a related lock. A sender or receiver thread grabs a random cipher and locks its associated lock. This way, lock requests are striped and the single lock bottleneck is removed. The pool size (and thus the lock striping) needs to be configurable.
> Improve performance of ENCRYPT protocol
> ---------------------------------------
>
> Key: JGRP-1722
> URL: https://issues.jboss.org/browse/JGRP-1722
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.4
> Reporter: Martin Gencur
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> A stress tests with the following setup showed that performance (reads and writes/sec) is halved when ENCRYPT protocol is enabled:
> Infinispan had distributed sync cache with 2 owners on 4 nodes, no transactions. The stress test used 10 threads on each node accessing 1024 byte entries, no conflicts on keys, 20 % writes, 80 % reads.
> It would be great if we could improve the performance of ENCRYPT protocol.
--
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, 2 months