[JBoss JIRA] (WFLY-4994) SPEC JMS 2007 benchmark fails due to performance drop with http-connector
by Dimitris Andreadis (JIRA)
[ https://issues.jboss.org/browse/WFLY-4994?page=com.atlassian.jira.plugin.... ]
Dimitris Andreadis commented on WFLY-4994:
------------------------------------------
[~flavia.rainone], [~jason.greene] can you please clean up this?
> SPEC JMS 2007 benchmark fails due to performance drop with http-connector
> -------------------------------------------------------------------------
>
> Key: WFLY-4994
> URL: https://issues.jboss.org/browse/WFLY-4994
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Alpha5
> Reporter: Ondřej Kalman
> Assignee: Flavia Rainone
> Priority: Blocker
> Attachments: standalone-full-ha-http-aio.xml, standalone-full-ha-http-aio.xml, standalone-full-ha-netty-bio-nio.xml, standalone-full-ha-netty-bio-nio.xml
>
>
> Hi, we have huge performance drop in SPEC JMS 2007 benchmark when we use http-connectors. Netty connectors seems to be working fine.
> Currently we are having troubles even with very low load of 50 SMAgents
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-4882) Security manager's maximum-permissions setting doesn't work
by Dimitris Andreadis (JIRA)
[ https://issues.jboss.org/browse/WFLY-4882?page=com.atlassian.jira.plugin.... ]
Dimitris Andreadis commented on WFLY-4882:
------------------------------------------
This has been hanging around, see linked JBEAP issue.
> Security manager's maximum-permissions setting doesn't work
> -----------------------------------------------------------
>
> Key: WFLY-4882
> URL: https://issues.jboss.org/browse/WFLY-4882
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager
> Affects Versions: 10.0.0.Alpha4, 10.0.0.Alpha6
> Reporter: Josef Cacek
> Assignee: Stefan Guilhen
> Priority: Critical
>
> Configuration of {{maximum-permissions}} attribute in {{/subsystem=security-manager/deployment-permissions=default}} doesn't work so the permissions for deployments can't be restricted.
> (The "_policy of the product installation_" in the words of EE specification is not enforced).
> If administrator specifies {{maximum-permissions}} in server configuration and also {{permissions.xml}} in the deployment, all permissions from the {{permissions.xml}} are granted even if the policies are in conflict.
> The {{maximum-permissions}} configuration has following meaning:
> _A set containing the maximum permission scope that can be granted to deployments or jars_
> The Java EE 7 platform specification (JSR 342) says in section EE.6.2.2.1:
> _If security permissions are declared that conflict with the policy of the product installation, the Java EE product must fail deployment of the application module._
> *Expected behavior:*
> * based on EE spec the deployment should fail
> * deployed application should not get more permissions than specified in the {{maximum-permissions}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-2010) RpcDispatcher/MessageDispatcher: don't copy the first anycast
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2010?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2010.
----------------------------
Resolution: Done
> RpcDispatcher/MessageDispatcher: don't copy the first anycast
> -------------------------------------------------------------
>
> Key: JGRP-2010
> URL: https://issues.jboss.org/browse/JGRP-2010
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8, 4.0
>
>
> If we have an anycast to targets B,C,D, this will be sent as 3 unicasts: to A, to B and to C. The original message is copied for each of the 3 target dests (only the headers are copied, not the payload). The copy is needed to prevent protocols from changing the (same) headers when the message is sent (or retransmitted).
> As an optimization, we don't need to copy the *first* message; in the above example, we need to copy only B and C.
> For anycasts to single destination, we don't need to copy anything.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-4682) standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/WFLY-4682?page=com.atlassian.jira.plugin.... ]
Flavia Rainone commented on WFLY-4682:
--------------------------------------
[~mnovak] I downloaded the server, and when I remove the messaging-activemq subsystem, I get an error when starting the server:
{{08:15:50,503 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0009: Starting weld service for deployment simple-servlet.war
08:15:51,943 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."simple-servlet.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."simple-servlet.war".WeldStartService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type JMSContext with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject @JMSConnectionFactory private SimpleServlet.context
at SimpleServlet.context(SimpleServlet.java:0)
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
08:15:51,952 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "simple-servlet.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"simple-servlet.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"simple-servlet.war\".WeldStartService: Failed to start service
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type JMSContext with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject @JMSConnectionFactory private SimpleServlet.context
at SimpleServlet.context(SimpleServlet.java:0)
}}
> standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-4682
> URL: https://issues.jboss.org/browse/WFLY-4682
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading, MSC
> Affects Versions: 9.0.0.CR1, 10.0.0.Alpha1
> Reporter: Miroslav Novak
> Assignee: Bartosz Baranowski
> Labels: duplicate
> Attachments: standalone-full.xml
>
>
> Deployment (Servlet, EJB, MDB) which is using Websphere MQ 8 resource adapter to send/receive messages from external Websphere MQ 8 instance is not loading "javax.jms.api" module. Deployment is using JMS api.
> This is change in behaviour against previous versions EAP 6/Widlfly 9.
> There is no error during deploy. Failures occur in the moment when deployment for example servlet is called. Following error is logged in EAP 7.0.0.DR2 log:
> {code}
> 08:57:24,835 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "servlet.war" with deployment "servlet.war"
> 08:57:24,838 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 1) WFLYDR0002: Content removed from location /home/mnovak/projects/eap-tests-wsmq/ibm-mq-testsuite/src/test/config/ibm8/install/jboss-eap-7.0/standalone/data/content/62/931347d12b65c80cd2201372be52f0494e361a/content
> 08:57:25,794 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /CleaningServlet/CleaningServlet: java.lang.NoClassDefFoundError: javax/jms/Message
> at org.jboss.as.test.ibm.mq.servlet.CleaningServlet.doGet(CleaningServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:274)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: javax.jms.Message from [Module "deployment.servlet.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> ... 30 more
> {code}
> Websphere MQ resource adapter is rar archive in deployments directory. It's not configured in module. Only way to force loading of "javax.jms.api" for deployment is to add Dependecies: javax.jms.api to MANIFEST.MF or add it to global-modules. This negatively affects usability.
> Can be javax.jms.api loaded for deployment by default for "full" and "full-ha" profile?
> I'm adding standalone-full.xml with configuration for EAP 7.0.0.DR2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ELY-415) Eliminate RuntimeExceptions thrown from SecurityRealm implementations.
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-415:
------------------------------------
Summary: Eliminate RuntimeExceptions thrown from SecurityRealm implementations.
Key: ELY-415
URL: https://issues.jboss.org/browse/ELY-415
Project: WildFly Elytron
Issue Type: Task
Components: Realms
Reporter: Darran Lofthouse
Priority: Critical
Fix For: 1.1.0.CR1
Where a realm is temporarily unavailable we have the RealmUnavailableException - in other cases however our API generally requires that null or empty representations are returned when identities can not be loaded or validation.
In a few cases RuntimeExceptions have crept into the implementations, we need to eliminate these as any code written according the API and not expecting them risks breaking for unexpected RuntimeExceptions.
Each method on the API should also be double checked to ensure it clearly documents what should happen if it can not return the desired result.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-2010) RpcDispatcher/MessageDispatcher: don't copy the first anycast
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2010?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2010:
--------------------------------
When sending a message with an AnycastAddress, no copy is needed, either
> RpcDispatcher/MessageDispatcher: don't copy the first anycast
> -------------------------------------------------------------
>
> Key: JGRP-2010
> URL: https://issues.jboss.org/browse/JGRP-2010
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.8, 4.0
>
>
> If we have an anycast to targets B,C,D, this will be sent as 3 unicasts: to A, to B and to C. The original message is copied for each of the 3 target dests (only the headers are copied, not the payload). The copy is needed to prevent protocols from changing the (same) headers when the message is sent (or retransmitted).
> As an optimization, we don't need to copy the *first* message; in the above example, we need to copy only B and C.
> For anycasts to single destination, we don't need to copy anything.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-2010) RpcDispatcher/MessageDispatcher: don't copy the first anycast
by Bela Ban (JIRA)
Bela Ban created JGRP-2010:
------------------------------
Summary: RpcDispatcher/MessageDispatcher: don't copy the first anycast
Key: JGRP-2010
URL: https://issues.jboss.org/browse/JGRP-2010
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 3.6.8, 4.0
If we have an anycast to targets B,C,D, this will be sent as 3 unicasts: to A, to B and to C. The original message is copied for each of the 3 target dests (only the headers are copied, not the payload). The copy is needed to prevent protocols from changing the (same) headers when the message is sent (or retransmitted).
As an optimization, we don't need to copy the *first* message; in the above example, we need to copy only B and C.
For anycasts to single destination, we don't need to copy anything.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-5715) Wildfly 9/10 removing deployments after a certain time
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-5715?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet commented on WFLY-5715:
-----------------------------------------
[~oleg.hoefling] Is there a way for you to connect to hipchat / irc for easier exchange ? Also could you attach your log files to https://issues.jboss.org/browse/WFCORE-1330 as this bug entry is closed.
> Wildfly 9/10 removing deployments after a certain time
> ------------------------------------------------------
>
> Key: WFLY-5715
> URL: https://issues.jboss.org/browse/WFLY-5715
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.2.Final, 10.0.0.CR4
> Environment: Ubuntu 12.04.5 LTS
> Reporter: Sven Ulrich
> Assignee: ehsavoie Hugonnet
> Attachments: Dummy.war, ifxjdbc_4.10.jar, server.log, standalone.xml
>
>
> I have setup a Wildfly 10 CR4 on a Ubuntu 12.04.5 LTS. The server is running fine.
> Now I want to deploye my jar files (jdbc driver and jee apps).
> All is uploaded via the management web interface running on the port 10010 (added offset of 20 because a WF8 is running on Port 8080)
> First I log into the web interface and navigate to the tab deployments. Then I use the button add.
> In the popup window:
> 1: Upload a new deployment
> 2: I choose ifxjdbc_4.10.jar for e.g.
> 3: In Verify upload enabled is set and everything else is standard
> 4: The upload takes round about 30sec.
> Now I can setup datasources for this driver and its works fine. My next step is to stop the server and restart it. Then the server wont start because the content is missing for the jar.
> It wont be an issue for me if i could be 100% sure that the server wont be restarted anytime :)
> I have added my standalone.xml and the log with hopefully all needed information.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1313) User with slash or backslash char in LDAP name cannot log in through security-realm
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1313?page=com.atlassian.jira.plugi... ]
Lin Gao reassigned WFCORE-1313:
-------------------------------
Assignee: Lin Gao (was: Darran Lofthouse)
> User with slash or backslash char in LDAP name cannot log in through security-realm
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-1313
> URL: https://issues.jboss.org/browse/WFCORE-1313
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Lin Gao
> Attachments: users.ldif
>
>
> According to LDAP specification [1], DN can contain slash char without escaping or escaped backslash, etc.
> I am not able to log in to management console with username "Slash/Char" or "Back\Slash". But I would be able to log in there.
> I can see this in Wireshark
> *Slash/Char*
> {code}
> LDAPMessage bindRequest(1) ""uid=Slash/Char",ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org" simple
> LDAPMessage bindResponse(1) invalidDNSyntax (Incorrect DN given : "uid=Slash/Char",ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org (0x22 0x75 0x69 0x64 0x3D 0x53 0x6C 0x61 0x73 0x68 0x2F 0x43 0x68 0x61 0x72 0x2
> {code}
> You can see there quotation marks around *uid=Slash/Char*.
> *Back\Slash*
> {code}
> LDAPMessage bindRequest(1) "uid=Back\\\Slash,ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org" simple
> LDAPMessage bindResponse(1) invalidDNSyntax (Incorrect DN given : uid=Back\\\Slash,ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org (0x75 0x69 0x64 0x3D 0x42 0x61 0x63 0x6B 0x5C 0x5C 0x5C 0x53 0x6C 0x61 0x73 0x6
> {code}
> You can see there three backslash chars.
> In my opinion problem can be somewhere around this
> {code}
> javax.naming.NameImpl.stringifyComp(String comp)
> {code}
> [1] https://tools.ietf.org/html/rfc2253#section-3
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1343) Memory leak in host controller
by Aparna Chaudhary (JIRA)
Aparna Chaudhary created WFCORE-1343:
----------------------------------------
Summary: Memory leak in host controller
Key: WFCORE-1343
URL: https://issues.jboss.org/browse/WFCORE-1343
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 1.0.0.Final
Reporter: Aparna Chaudhary
Assignee: Brian Stansberry
Priority: Critical
Attachments: WFCORE-992-HC-Leak.PNG
The ManagedServerProxy class in host-controller contains a memory leak. The leak can be reproduced by performing multiple requests to HTTP management API.
{noformat}
http://<host>:9990/management/host/host0/server/server0/core-service/platform-mbean/type/memory?include-runtime=true
{noformat}
Applying the fix proposed in WFCORE-992 solves the leak.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months