[JBoss JIRA] (JBWEB-290) Optimize string literals inside jsp expressions
by Andrig Miller (JIRA)
[ https://issues.jboss.org/browse/JBWEB-290?page=com.atlassian.jira.plugin.... ]
Andrig Miller commented on JBWEB-290:
-------------------------------------
I will add to what Stale is saying. This is one of our biggest memory allocation issues, and we need a fix for this to get into EAP 6.3.
> Optimize string literals inside jsp expressions
> ------------------------------------------------
>
> Key: JBWEB-290
> URL: https://issues.jboss.org/browse/JBWEB-290
> Project: JBoss Web
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Tomcat
> Affects Versions: JBossWeb-3.0.0.Final
> Reporter: John O'Hara
> Assignee: Remy Maucherat
>
> After setting genStringAsCharArray=true, we continue to see StringBuilder concatenating string literals for each jsp request for some of our jsp pages; instead of creating a static char[].
> This occurs when a string literal is included in a jsp expression, e.g.;
> <%="<INPUT type=\"hidden\" name=\"name\" value=\"" + obj.getName() + "\">"%>
> Is it possible to identify string literals inside expressions during the tokenization phase of parsing jsp pages in apache jasper and treat them as text nodes so that the apache jasper generator can apply the same optimizations as string literals outside the jsp expression?
--
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 edited comment on JGRP-1722 at 2/27/14 12:54 PM:
----------------------------------------------------------
OK, so Cipher is not reentrant, so we cannot use it from multiple threads. Both encrypting and decrypting a message is synchronized, so we cannot do this in parallel.
However, we could create a pool of Ciphers for parallel encryption / decryption...
was (Author: belaban):
OK, so Cipher is not reentrant, so we cannot use it from multiple threads. However, we could create a pool of Ciphers for parallel encryption / decryption...
> 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
[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:
--------------------------------
OK, so Cipher is not reentrant, so we cannot use it from multiple threads. However, we could create a pool of Ciphers for parallel encryption / decryption...
> 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
[JBoss JIRA] (WFLY-3036) Forwarded POST request becomes a GET request
by Matti Tahvonen (JIRA)
Matti Tahvonen created WFLY-3036:
------------------------------------
Summary: Forwarded POST request becomes a GET request
Key: WFLY-3036
URL: https://issues.jboss.org/browse/WFLY-3036
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.0.0.Final
Reporter: Matti Tahvonen
Assignee: Stuart Douglas
POST requests that get forwarded (at least due to <security-constraint> rule) are reported as GET requests when the request arrives to the destination.
Now e.g. Vaadin login UI that sends POST request (XHR) to the "original" address dies as Vaadin servlet returns html instead of JSON.
The same setup works in JBoss 7.1 and Glassfish.
The issue (and workaround) is describe in the github project:
https://github.com/mstahv/vaadin-cdi-jaas-jbossas-example/
--
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:
--------------------------------
Hmm, the biggest chunk of CPU (by far) according to jmc is spent in {{com.sun.crypto.provider.AESCrypt.decryptBlock()}} (30%) and {{com.sun.crypto.provider.AESCrypt.encryptBlock()}} (26%). A total of over 64% is spent in the {{com.sun.crypto.provider}} package !
I'll try to improve other things, but I won't be able to do much about this. Pinging [~NadirX] to take a look; perhaps a different encryption algorithm (or a smaller key size) will help, but I doubt it. Looks like encryption does have a price tage to it...
One thing I'll investigate is whether encryption is done sequentially, using the same cipher, or whether we can parallelize this. If we can, then even a costly encryption / decryption alg won't have much impact.
> 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
[JBoss JIRA] (WFLY-3031) Management audit logging logs parallel boot ops in separate records
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3031?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-3031:
-----------------------------------
Summary: Management audit logging logs parallel boot ops in separate records (was: Management audit logging does not log parallel boot ops)
Issue Type: Enhancement (was: Bug)
Fix Version/s: 9.0.0.CR1
(was: 8.0.1.Final)
Description:
The parallel boot ops (i.e. the subsystem stuff) are logged in separate log records from the other stuff.
This is questionable because they are actually all part of the same execution. The main execution blocks for the parallel ops.
was:
The parallel boot ops (i.e. the subsystem stuff) are not part of the set recorded and logged.
Priority: Major (was: Critical)
I was wrong in my initial report; these actually are logged, just somewhat oddly. I'm not certain we should fix this, but my instinct is we should.
> Management audit logging logs parallel boot ops in separate records
> -------------------------------------------------------------------
>
> Key: WFLY-3031
> URL: https://issues.jboss.org/browse/WFLY-3031
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 9.0.0.CR1
>
>
> The parallel boot ops (i.e. the subsystem stuff) are logged in separate log records from the other stuff.
> This is questionable because they are actually all part of the same execution. The main execution blocks for the parallel ops.
--
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-1188) allow custom-formatter configuration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1188?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1188:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 994661|https://bugzilla.redhat.com/show_bug.cgi?id=994661] from POST to MODIFIED
> allow custom-formatter configuration
> ------------------------------------
>
> Key: WFLY-1188
> URL: https://issues.jboss.org/browse/WFLY-1188
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: Aleksandar Kostadinov
> Assignee: James Perkins
> Labels: as7, formatting, logging
> Fix For: 8.0.0.CR1
>
>
> Currently only *org.jboss.logmanager.formatters.PatternFormatter* is supported in JBoss AS7 configuration. It would be very useful to allow specifying a custom-formatter (e.g *java.util.logging.XMLFormatter*).
> At the moment one can specify another formatter in logging.properties but once the logging subsystem is initialized, the settings in logging.properties get overridden.
> A workaround would be to disable logging subsystem but that has drawbacks.
--
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] (LOGMGR-95) Log4j Logger.getParent() inconsistent
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-95?page=com.atlassian.jira.plugin.... ]
James Perkins reassigned LOGMGR-95:
-----------------------------------
Assignee: James Perkins (was: David Lloyd)
> Log4j Logger.getParent() inconsistent
> -------------------------------------
>
> Key: LOGMGR-95
> URL: https://issues.jboss.org/browse/LOGMGR-95
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: James Livingston
> Assignee: James Perkins
>
> Log4j Loggers have a getParent() method, whose return value is set up by JBossLogManagerFacade.updateParents(). The method locates the closest parent node which has an existing Log4J logger created *at the time*. This results in the parent being different depending on the order Log4j loggers are used in.
> Consider:
> Logger.getLogger("a");
> Logger.getLogger("a.b.c");
> Logger.getLogger("a.b");
> When the second line causes updateParents() to be called, LoggerNode.getOrCreate() has already created the intermediate "a.b" node. That does not yet have a Log4j Logger created, so the Logger for "a" is returned. Original log4j would have returned "a.b" due to it using the parent structure in the implementation.
--
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