[JBoss JIRA] (WFLY-904) The property AuthorizationManager is null exceptions and NPE on SimpleSecurityManager when connecting firstly from a remote client
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-904?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration updated WFLY-904:
-----------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1330677
Bugzilla Update: Perform
> The property AuthorizationManager is null exceptions and NPE on SimpleSecurityManager when connecting firstly from a remote client
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-904
> URL: https://issues.jboss.org/browse/WFLY-904
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Environment: Eclipse Juno SR2 with JBoss Tools, Mac OS X, Sun JDK 6
> Reporter: Fernando Nasser
> Assignee: Darran Lofthouse
> Labels: eap6, investigation_required
> Fix For: 9.0.0.CR1
>
> Attachments: NPEinSimpleSecurityManager, PBOX000075, QSecuredEJB.jar, QSecuredEJB.zip, SecurityRelatedSettings
>
>
> Description of problem:
> If one tries and use security enabled EJBs from a remote client (authenticated connection) before connecting first from a servlet both a Server NPE and an erroneous exception are thrown. However, if one uses some servlet-based authentication first, the missing field is "primed" and from that point on the remote application can use the secure EJBs normally, proper Role authorization is checked and enforced etc. With absolutely no changes in configuration, code (incl. annotation) whatsoever. Any number of remote client connections will succeed until you restart the server. Then the errors are back, until you "prime" the Server by connecting using a Servlet.
> More complete data is attached, but here are some info:
> NPE is thrown at:
> org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:394)
> Bean method invocation fails with exceptions containing the message:
> JBAS011048: Failed to construct component instance
> I am using the "other" security context for testing.
> I am running the Server in standalone mode.
> When I say remote I mean not in the Server, but I am running my client from localhost.
> Version-Release number of selected component (if applicable): Seen on EAP 6.1.0 alpha (apparently present on AS 7.1.1 as well).
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-2059) UPerf: measure latency
by Bela Ban (JIRA)
Bela Ban created JGRP-2059:
------------------------------
Summary: UPerf: measure latency
Key: JGRP-2059
URL: https://issues.jboss.org/browse/JGRP-2059
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 3.6.10, 4.0
Currently, UPerf only measures throughput. Change this to also measure latency (RTTs for blocking requests)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1187) Embedded server start / stop / start with new --jboss-home continues to refer to previous server.log
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1187?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1187:
----------------------------------------------
The EmbeddedServer is setting the right LogContext, the problem is that some of the Server loggers (that are annotated with @MessageLogger, e.g.: ServerLogger) are statics and their implementation is bound to the Logger retrieved at construction time.
When such static annotated loggers are instantiated, the LogContext is accessed and the "first server" context is retrieved to build a final Logger delegate. The delegate is internally used by the @MessageLogger to delegate actual logging.
So all the static @MessageLogger are bound to a given logging configuration, whatever the changes that can occur in the LogContext.
When the second server is started, the @MessageLogger are not refreshed.
Actually a layer (JBoss module) manages to log in the second file, this is due to the fact that the LoggingManager is re-set each time an embedded server is started.
I don't know this code, but I could suggest a possible fix.
The DelegatingBasicLogger could define a LoggerProvider interface. @MessageLogger would implement this interface and passes it at construction time. Something like:
public class DelegatingBasicLogger {
public interface LoggerProvider {
public Logget getLogger();
}
DelegatingBasicLogger(LoggerProvider provider) { this.provider = provider; }
....
}
Then for subclass:
class MyLogger extends DelegatingBasicLogger {
MyLogger() {
super(()->LogContext.getLogContext());
}
Would that makes sense?
> Embedded server start / stop / start with new --jboss-home continues to refer to previous server.log
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1187
> URL: https://issues.jboss.org/browse/WFCORE-1187
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> - start-embedded-server --jboss-home=/foo/bar1
> - stop-embedded-server
> - start-embedded-server --jboss-home=/foo/bar2
> -- server.log in /foo/bar1/standalone/logs/server.log is still written to.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6489) Distributable session may not exist after redirect to same node with optimistic locking.
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6489?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6489:
------------------------------------
[~glavoie] I think you misunderstood. By "attribute replication", I mean fine granularity session -> cache entry mapping, where each session attribute is stored in a separate cache entry. This is enabled via <replication-config><replication-granularity>ATTRIBUTE</replication-granularity></replication-config> within jboss-web.xml. This is a typical optimization strategy that only requires replication of modified session attributes, rather than the whole session. Support for mutable session attributes with a non-tx cache is a separate issue. I've created a jira to add support for this: https://issues.jboss.org/browse/WFLY-6522
"We certainly don't want to replicate the whole session every times it changes as it is currently too big and we had a lot of performance issues with it in the past."
I strongly encourage you to leverage the marshalling api to supply externalizers for your session attribute POJOs. This can considerably reduce the size of the replication payload of your session attributes by eliminating the need to replicate class descriptors.
https://github.com/wildfly/wildfly/blob/master/clustering/marshalling/api...
To use, implement this interface for each custom session attribute class, and enumerate your externalizer classes in a /META-INF/services/org.wildfly.clustering.marshalling.Externalizer file within your WAR.
> Distributable session may not exist after redirect to same node with optimistic locking.
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6489
> URL: https://issues.jboss.org/browse/WFLY-6489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.1.Final, 10.0.0.Final, 10.1.0.Final
> Reporter: Gabriel Lavoie
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: wfly-6489-showcase.zip, wildfly-10-session-issue.zip
>
>
> I'm currently working on porting an application running on EAP 6.1 to WildFly 10 and am encountering multiple session/authentication issues with clustering enabled. Our login flow currently starts from a servlet that accepts the credentials, creates the session, then redirect to the welcome page.
> The first time we execute this flow after the startup of a node, the welcome page can't see at all the session created previously.
> - request.getSession() creates yet another session and a new session cookie is returned.
> - request.getSession(false) returns "null"
> On the second attempt, the flow works as expected.
> The issue can be reproduced on both a single node or a two nodes cluster, as long as <distributable /> is enabled in web.xml.
> We are currently using the master build https://ci.jboss.org/hudson/job/WildFly-latest-master/2244/, but the problem has been noticed on 10.0.0-Final and also 8.2.1-Final.
> I attached a sample web application that I used to reproduce the issue. Our standalone.xml is also included with the clustering configuration we've been using for the web/session cache.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-2057) Message bundler improvements
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2057?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2057:
--------------------------------
The longer it takes to add a message to the hashmap, the more messages are sent by the bundler and that increases _throughput_. Apparently, lock contention on the send-queue in {{TransferQueueBundler}} between the senders (producers) and the sending thread (consumer) leads to more messages accumulating in the queue and therefore bigger message bundles with more messages.
{{SenderSendsBundler}} has much less contention, only an AtomicLong is incremented and decremented, and so fewer messages are in a batch, with the result being less throughput.
Latency, however, is slightly better with {{SenderSendsBundler}}. Plus, its performance gets much better with more sending threads.
> Message bundler improvements
> ----------------------------
>
> Key: JGRP-2057
> URL: https://issues.jboss.org/browse/JGRP-2057
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> * {{SingletonAddress}} is not needed anymore as we removed the shared transport in 4.0
> ** This slows down the bundler as it is used as key to the bundler hashmaps
> * {{SenderSendsBundler}}: send messages outside the lock scope. This requires us to use a number of bundler hashmaps, or making a shallow copy of the buckets of the current hashmap, before clearing it
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-2057) Message bundler improvements
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2057?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2057:
--------------------------------
Sending messages outside the lock scope didn't make a difference as the serialization and sending took only ~20 microsecs (on my mac mini). Also, we can't just use a pool of hashmaps: we also need to include {{count}} and the output stream in that structure.
> Message bundler improvements
> ----------------------------
>
> Key: JGRP-2057
> URL: https://issues.jboss.org/browse/JGRP-2057
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> * {{SingletonAddress}} is not needed anymore as we removed the shared transport in 4.0
> ** This slows down the bundler as it is used as key to the bundler hashmaps
> * {{SenderSendsBundler}}: send messages outside the lock scope. This requires us to use a number of bundler hashmaps, or making a shallow copy of the buckets of the current hashmap, before clearing it
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6554) Cache configuration are not eagerly defined in Cache Container
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6554?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-6554.
------------------------------
Resolution: Rejected
As of WF10, cache configurations are installed using PASSIVE mode (previously, they were ON_DEMAND). This means that they will be defined within the parent cache manager as soon as their dependencies are satisfied (e.g. transaction manager, MBeanServer, etc). The caches themselves are still installed using ON_DEMAND mode.
JndiInfinispanRegionFactory should not be used within the context of WildFly. WildFly includes a customized region factory implementation that properly integrate with Infinispan and JBoss MSC.
See:
https://github.com/wildfly/wildfly/blob/10.0.0.Final/jpa/hibernate5/src/m...
> Cache configuration are not eagerly defined in Cache Container
> --------------------------------------------------------------
>
> Key: WFLY-6554
> URL: https://issues.jboss.org/browse/WFLY-6554
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
>
> In WF8 we used the cache configuration start="EAGER" to force the initialization of the cache configuration.
> In my scenario, we especially used that trick to define all cache configuration (i.e. entity / timestamps / local-query) in the hibernate cache container before any of our war was deployed. Doing so, when wiring the EntityManager programatically (in our application), we were able to depend on the JNDIRegionFactory without getting any NullPointerException/etc.
> This trick has only one bad side effect, which was the creation of unecessary caches.
> Now in WF10, the eager feature is gone and it seems that even if the cache container is available at startup (as discussed in: https://developer.jboss.org/thread/259151) the defined caches are not.
> I do not know if this is a bug or this is by design but this seems wrong to me.
> If we define caches within standalone.xml, I would definitly like to have them defined at the container level. I think it's fair to assume that when pulling the CacheManager all defined caches should have been there.
> I would suggest that when reading all the infinispan subsystem, each cache contained in each cache container be eagerly defined to avoid any issue (and I really meant "defined" and not "started").
> Doing so this would resolve our EntityManager second level cache bootstraping without relying on our application to define the missing cache configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-974) Cli calls leak memory in Host Controller when reading children names in domain mode
by Michael Noack (JIRA)
[ https://issues.jboss.org/browse/WFCORE-974?page=com.atlassian.jira.plugin... ]
Michael Noack edited comment on WFCORE-974 at 4/26/16 10:26 AM:
----------------------------------------------------------------
[~proesler_ucsd] Sorry for the late reply. I had to first get approval to release the template and the relevant scripts and to be honest forgot about it once I got it for a few days.
-Since github seems to have trouble at the moment, I published it to gitlab:- https://gitlab.com/noamik/wildfly-jvm-monitor
Edit:
I pushed the code and template to github: https://github.com/noamik/wildfly-jvm-monitor
was (Author: michael.noack):
[~proesler_ucsd] Sorry for the late reply. I had to first get approval to release the template and the relevant scripts and to be honest forgot about it once I got it for a few days.
-Since github seems to have trouble at the moment, I published it to gitlab: https://gitlab.com/noamik/wildfly-jvm-monitor-
Edit:
I pushed the code and template to github: https://github.com/noamik/wildfly-jvm-monitor
> Cli calls leak memory in Host Controller when reading children names in domain mode
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-974
> URL: https://issues.jboss.org/browse/WFCORE-974
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Environment: CentOS 6.5:
> # java -version
> java version "1.7.0_79"
> OpenJDK Runtime Environment (rhel-2.5.5.2.el7_1-x86_64 u79-b14)
> OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
> CentOS 7.0:
> # java -version
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
> Reporter: Michael Noack
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 2.0.0.Beta7
>
> Attachments: host-controller-jvm.png
>
>
> Calling the cli using the command:
> {{jboss-cli.sh --connect --user="myuser" --password="mypassword" --command=":read-children-names(child-type=host)"}}
> leaks memory to old gen. Eventually the host controller goes OOM if called to often.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-974) Cli calls leak memory in Host Controller when reading children names in domain mode
by Michael Noack (JIRA)
[ https://issues.jboss.org/browse/WFCORE-974?page=com.atlassian.jira.plugin... ]
Michael Noack edited comment on WFCORE-974 at 4/26/16 10:26 AM:
----------------------------------------------------------------
[~proesler_ucsd] Sorry for the late reply. I had to first get approval to release the template and the relevant scripts and to be honest forgot about it once I got it for a few days.
-Since github seems to have trouble at the moment, I published it to gitlab:- -https://gitlab.com/noamik/wildfly-jvm-monitor-
Edit:
I pushed the code and template to github: https://github.com/noamik/wildfly-jvm-monitor
was (Author: michael.noack):
[~proesler_ucsd] Sorry for the late reply. I had to first get approval to release the template and the relevant scripts and to be honest forgot about it once I got it for a few days.
-Since github seems to have trouble at the moment, I published it to gitlab:- https://gitlab.com/noamik/wildfly-jvm-monitor
Edit:
I pushed the code and template to github: https://github.com/noamik/wildfly-jvm-monitor
> Cli calls leak memory in Host Controller when reading children names in domain mode
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-974
> URL: https://issues.jboss.org/browse/WFCORE-974
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Environment: CentOS 6.5:
> # java -version
> java version "1.7.0_79"
> OpenJDK Runtime Environment (rhel-2.5.5.2.el7_1-x86_64 u79-b14)
> OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
> CentOS 7.0:
> # java -version
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
> Reporter: Michael Noack
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 2.0.0.Beta7
>
> Attachments: host-controller-jvm.png
>
>
> Calling the cli using the command:
> {{jboss-cli.sh --connect --user="myuser" --password="mypassword" --command=":read-children-names(child-type=host)"}}
> leaks memory to old gen. Eventually the host controller goes OOM if called to often.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years