[JBoss JIRA] (JGRP-2126) Table.removeMany() creates unneeded temporary list
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2126?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2126:
--------------------------------
Added Table.removeMany():
{code:java}
<R> R removeMany(final AtomicBoolean processing, boolean nullify, int max_results, Predicate<T> filter, Supplier<R> result_creator, BiConsumer<R,T> accumulator, Predicate<R> result_validator)
{code}, which accepts a result creator, accumulator and validator (similar to Stream.collect()).
Both NAKACK2 and UNICAST3 create a MessageBatch and use it to move messages from the table to the batch, avoiding a temporary list creation.
> Table.removeMany() creates unneeded temporary list
> --------------------------------------------------
>
> Key: JGRP-2126
> URL: https://issues.jboss.org/browse/JGRP-2126
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR3
> Fix For: 4.0
>
>
> When a thread acquires the CAS in NAKACK2 or UNICAST3 to deliver messages, it calls Table.removeMany() which removes messages that satisfy a condition and return them as a list. Next, a MessageBatch is created off of that list and passed up.
> The creation of the temp list is unnecessary; instead create a properly sized MessageBatch and make Table.removeMany() add the messages directly into the batch.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (WFLY-7838) EJBClient user transaction is not propagated properly to the receiver
by Mate Varga (JIRA)
[ https://issues.jboss.org/browse/WFLY-7838?page=com.atlassian.jira.plugin.... ]
Mate Varga updated WFLY-7838:
-----------------------------
Attachment: wf-txn-fix.patch
> EJBClient user transaction is not propagated properly to the receiver
> ---------------------------------------------------------------------
>
> Key: WFLY-7838
> URL: https://issues.jboss.org/browse/WFLY-7838
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: not relevant
> Reporter: Mate Varga
> Attachments: wf-txn-fix.patch
>
>
> Setup:
> - WF 10.1.0.Final
> - two deployments, one EAR and one WAR
> - EAR exposes EJB methods (SFSBs and SLSBs)
> - WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
> Problem:
> The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
> - LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
> - EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
> - processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
> - later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
> - it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
> - it does not find the userTransaction there
> It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (WFLY-7838) EJBClient user transaction is not propagated properly to the receiver
by Mate Varga (JIRA)
[ https://issues.jboss.org/browse/WFLY-7838?page=com.atlassian.jira.plugin.... ]
Mate Varga updated WFLY-7838:
-----------------------------
Description:
Setup:
- WF 10.1.0.Final
- two deployments, one EAR and one WAR
- EAR exposes EJB methods (SFSBs and SLSBs)
- WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
Problem:
The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
- LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
- EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
- processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
- later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
- it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
- it does not find the userTransaction there
It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
I've attached a patch that fixes the problem for me.
was:
Setup:
- WF 10.1.0.Final
- two deployments, one EAR and one WAR
- EAR exposes EJB methods (SFSBs and SLSBs)
- WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
Problem:
The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
- LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
- EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
- processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
- later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
- it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
- it does not find the userTransaction there
It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
> EJBClient user transaction is not propagated properly to the receiver
> ---------------------------------------------------------------------
>
> Key: WFLY-7838
> URL: https://issues.jboss.org/browse/WFLY-7838
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: not relevant
> Reporter: Mate Varga
> Attachments: wf-txn-fix.patch
>
>
> Setup:
> - WF 10.1.0.Final
> - two deployments, one EAR and one WAR
> - EAR exposes EJB methods (SFSBs and SLSBs)
> - WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
> Problem:
> The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
> - LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
> - EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
> - processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
> - later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
> - it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
> - it does not find the userTransaction there
> It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
> I've attached a patch that fixes the problem for me.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (WFLY-7412) A security-domain can only load login-modules from a single JBoss module
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/WFLY-7412?page=com.atlassian.jira.plugin.... ]
Peter Palaga commented on WFLY-7412:
------------------------------------
I have submitted a PR that adds a test for this fix https://github.com/wildfly/wildfly/pull/9508
> A security-domain can only load login-modules from a single JBoss module
> --------------------------------------------------------------------------
>
> Key: WFLY-7412
> URL: https://issues.jboss.org/browse/WFLY-7412
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Derek Horton
> Assignee: Stefan Guilhen
> Fix For: 11.0.0.Alpha1
>
>
> A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates.
> For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module:
> <security-domain name="jmx-console" cache-type="default">
> <authentication>
> <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> </login-module>
> <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required">
> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/>
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> </login-module>
> </authentication>
> </security-domain>
> Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (WFLY-7838) EJBClient user transaction is not propagated properly to the receiver
by Mate Varga (JIRA)
[ https://issues.jboss.org/browse/WFLY-7838?page=com.atlassian.jira.plugin.... ]
Mate Varga updated WFLY-7838:
-----------------------------
Description:
Setup:
- WF 10.1.0.Final
- two deployments, one EAR and one WAR
- EAR exposes EJB methods (SFSBs and SLSBs)
- WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
Problem:
The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
- LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
- EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
- processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
- later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
- it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
- it does not find the userTransaction there
It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
was:
Setup:
- WF 10.1.0.Final
- two deployments, one EAR and one WAR
- EAR exposes EJB methods (SFSBs and SLSBs)
- WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
Problem:
The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
- LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
- EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
- processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
- later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
- it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
- it does not find the userTransaction there
It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
In other words, if this line:
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
would be
{{final TransactionID transactionID = (TransactionID) context.getContextData().get(AttachmentKeys.TRANSACTION_ID_KEY);}}
then it'd probably work ...
> EJBClient user transaction is not propagated properly to the receiver
> ---------------------------------------------------------------------
>
> Key: WFLY-7838
> URL: https://issues.jboss.org/browse/WFLY-7838
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: not relevant
> Reporter: Mate Varga
>
> Setup:
> - WF 10.1.0.Final
> - two deployments, one EAR and one WAR
> - EAR exposes EJB methods (SFSBs and SLSBs)
> - WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
> Problem:
> The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
> - LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
> - EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
> - processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
> - later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
> - it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
> - it does not find the userTransaction there
> It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (WFLY-7838) EJBClient user transaction is not propagated properly to the receiver
by Mate Varga (JIRA)
[ https://issues.jboss.org/browse/WFLY-7838?page=com.atlassian.jira.plugin.... ]
Mate Varga updated WFLY-7838:
-----------------------------
Description:
Setup:
- WF 10.1.0.Final
- two deployments, one EAR and one WAR
- EAR exposes EJB methods (SFSBs and SLSBs)
- WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
Problem:
The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
- LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
- EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
- processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
- later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
- it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
- it does not find the userTransaction there
It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
In other words, if this line:
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
would be
{{final TransactionID transactionID = (TransactionID) context.getContextData().get(AttachmentKeys.TRANSACTION_ID_KEY);}}
then it'd probably work ...
was:
Setup:
- WF 10.1.0.Final
- two deployments, one EAR and one WAR
- EAR exposes EJB methods (SFSBs and SLSBs)
- WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
Problem:
The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
- LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
- EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
- processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
- later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
- it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
- it does not find the userTransaction there
It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
In other words, if this line:
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
would be
`final TransactionID transactionID = (TransactionID) context.getContextData().get(AttachmentKeys.TRANSACTION_ID_KEY);`
then it'd probably work ...
> EJBClient user transaction is not propagated properly to the receiver
> ---------------------------------------------------------------------
>
> Key: WFLY-7838
> URL: https://issues.jboss.org/browse/WFLY-7838
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Environment: not relevant
> Reporter: Mate Varga
>
> Setup:
> - WF 10.1.0.Final
> - two deployments, one EAR and one WAR
> - EAR exposes EJB methods (SFSBs and SLSBs)
> - WAR uses wildfly-ejb-client-bom 10.1.0 to call remote EJBs
> Problem:
> The client uses bean-managed transactions. The problem is that transactions are not propagated properly to the EJB side, therefore instead of using the existing BMT, container will use CMT. The flow in detail:
> - LocalEjbReceiver#processInvocation receives an EJBClientInvocationContext
> - EJBClientInvocationContext contains contextData, which was populated by the client. contextData correctly contains the appropriate UserTransactionId
> - processInvocation extracts the transaction Id and puts it into the interceptorContext's context data (NOT into privateData)
> - later in the interceptor chain, control reaches EJBRemoteTransactionPropagatingInterceptor, which is responsible for checking whether there is an user transaction present.
> - it tries to fetch the transaction ID from the interceptorContext's privateData (NOT from contextData)
> - it does not find the userTransaction there
> It looks to me that either EJBRemoteTransactionPropagatingInterceptor should look look for the userTransaction in contextData, or LocalEjbReceiver should put the userTransaction ID into privateData.
> In other words, if this line:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
> would be
> {{final TransactionID transactionID = (TransactionID) context.getContextData().get(AttachmentKeys.TRANSACTION_ID_KEY);}}
> then it'd probably work ...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years