[JBoss JIRA] (WFLY-10258) Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka edited comment on WFLY-10258 at 4/19/18 8:51 AM:
-----------------------------------------------------------------
I've just checked the issue and I would mark it as expected behavior in a way.
First you I would expect that you will get the 1PC behavior if you switch the order of the operation in your bean at the {{server-1}}. If you: first call {{server-2}} and then enlist the {{dummy XAResource}} then you should observe the 1PC behaviour.
In case that you first enlist the {{dummy XAResource}} and you then call the {{server-2}} then you will observe the 2PC behaviour.
The transaction manager is not capable to decide what will be result of the operation while calling from server one to server two. The scenario is like
* you call from {{server-1}} to {{server-2}}
* the app server/transaction manager can see you are working with some XAResource (in this case it's a ejb remote call to the {{server-2}}) thus the remote call is enlisted into the transaction
* the {{server-2}} makes some operations (writing data to a database, it can make the operations in a completely new transaction too ({{REQUIRES_NEW}}) but the {{server-1}} does not know if there were some actions provided or not up to the time the {{prepare}} call is executed for the {{ejb remote XAResoruce}} at the {{server-1}}
* you enlist {{dummy XAResource}}
* the business method ends and transaction manager starts with the 2PC
* transaction manager can see there are two XAResources to process, it starts with the first one, transaction manager calls {{ejb remote XAResource.prepare}} while there was no data manipulation (or no XAResource enlisted) at the {{server-2}} (as all work was done in a new transaction) thus the correct return code {{TwoPhaseOutcome.PREPARE_READONLY)}} is returned
* the transaction manager wants to run {{dummy XAResource.prepare}} but it spot it's working with the first, and the only one, resource at the list (the previous one was skipped) - thus 1PC is applied and the {{dummy XAResource}} is just committed.
On the other hand in case if {{dummy XAResource}} is in order as the first participant the transaction manager can see there are two resources in the 2PC to process thus it has to call {{prepare}} on the first one and the {{dummy XAResource}} is prepared. Then the other resource {{ejb remote XAResource}} returns {{TwoPhaseOutcome.PREPARE_READONLY}} but the {{dummy}} one is already prepared.
Anyway I would consider this as expected.
was (Author: ochaloup):
I've just checked the issue and I would mark it as expected behavior in a way.
First you I would expect that you will get the 1PC behavior if you switch the order of the operation in your bean at the {{server-1}}. If you: first call {{server-2}} and then enlist the {{dummy XAResource}} then you should observe the 1PC behaviour.
In case that you first enlist the {{dummy XAResource}} and you then call the {{server-2}} then you will observe the 2PC behaviour.
The transaction manager is not capable to decide what will be result of the operation while calling from server one to server two. The scenario is like
* you call from {{server-1}} to {{server-2}}
* the app server/transaction manager can see you are working with some XAResource (in this case it's a ejb remote call to the {{server-2}}) thus the remote call is enlisted into the transaction
* the {{server-2}} makes some operations (writing data to a database, it can make the operations in a completely new transaction too ({{REQUIRES_NEW}}) but the {{server-1}} does not know if there were some actions provided or not up to the time the {{prepare}} call is executed for the {{ejb remote XAResoruce}} at the {{server-1}}
* you enlist {{dummy XAResource}}
* the business method ends and transaction manager starts with the 2PC
* transaction manager can see there are two XAResources to process, it starts with the first one, transaction manager calls {{ejb remote XAResource.prepare}} while there was no data manipulation (or no XAResource enlisted) at the {{server-2}} (as all work was done in a new transaction) thus the correct return code {{TwoPhaseOutcome.PREPARE_READONLY)}} is returned
* the transaction manager wants to run {{dummy XAResource.prepare}} but it can it's in fact the first and only resource at the list (the previous one was skipped). There are no other resources thus 1PC is applied and the {{dummy XAResource}} is just committed.
On the other hand in case if {{dummy XAResource}} is in order as the first participant the transaction manager can see there are two resources in the 2PC to process thus it has to call {{prepare}} on the first one and the {{dummy XAResource}} is prepared. Then the other resource {{ejb remote XAResource}} returns {{TwoPhaseOutcome.PREPARE_READONLY}} but the {{dummy}} one is already prepared.
Anyway I would consider this as expected.
> Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-10258
> URL: https://issues.jboss.org/browse/WFLY-10258
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 12.0.0.Final
> Reporter: Jörg Bäsner
>
> Scenario:
> - server-1 (intermediary)
> -- Running standalone profile
> -- Has a remote-outbound-connection pointing at server-2 through server-2's public IP address
> -- Intermediary bean need to lookup the Target bean in server-2 and also inject the {{TransactionManager}}
> -- Intermediary bean need to enlist a _dummy_ XAResource
> - server-2 (target)
> -- disable {{JBOSS-LOCAL-USER}} auth
> -- Target bean needs to be annotated with {{@REQUIRES_NEW}} (important)
> - Standalone EJB client invokes an intermediary bean server-1, which as a result invokes target bean on server-2.
> The _dummy_ XAResource should log in the {{commit}} method whether one-phase optimization is being used like:
> {code}
> @Override
> public void commit(Xid arg0, boolean onePhaseOptim) throws XAException {
> logger.info("-- Committing in the client resource. One-phase optimisation is: " + onePhaseOptim + " --"
> + (onePhaseOptim ? "" : " -> TWO-PHASE COMMIT !!!"));
> }
> {code}
> In this scenario it is expected that the one-phase optimization is being used!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10257) Cannot add non-anonymous entries to authentication configuration via console
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10257?page=com.atlassian.jira.plugin... ]
Claudio Miranda commented on WFLY-10257:
----------------------------------------
Can you try with the new web console ? It was merged in wildfly today.
> Cannot add non-anonymous entries to authentication configuration via console
> ----------------------------------------------------------------------------
>
> Key: WFLY-10257
> URL: https://issues.jboss.org/browse/WFLY-10257
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Reporter: David Lloyd
> Assignee: Harald Pehl
> Priority: Critical
>
> If you try to add an authentication configuration which includes an authentication-name (i.e. is not anonymous), you get an error because the "anonymous" attribute is present even though it is not valid due to the use of alternatives.
> This appears to be a realization of a more general problem handling alternative attribute sets.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10258) Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka edited comment on WFLY-10258 at 4/19/18 8:49 AM:
-----------------------------------------------------------------
I've just checked the issue and I would mark it as expected behavior in a way.
First you I would expect that you will get the 1PC behavior if you switch the order of the operation in your bean at the {{server-1}}. If you: first call {{server-2}} and then enlist the {{dummy XAResource}} then you should observe the 1PC behaviour.
In case that you first enlist the {{dummy XAResource}} and you then call the {{server-2}} then you will observe the 2PC behaviour.
The transaction manager is not capable to decide what will be result of the operation while calling from server one to server two. The scenario is like
* you call from {{server-1}} to {{server-2}}
* the app server/transaction manager can see you are working with some XAResource (in this case it's a ejb remote call to the {{server-2}}) thus the remote call is enlisted into the transaction
* the {{server-2}} makes some operations (writing data to a database, it can make the operations in a completely new transaction too ({{REQUIRES_NEW}}) but the {{server-1}} does not know if there were some actions provided or not up to the time the {{prepare}} call is executed for the {{ejb remote XAResoruce}} at the {{server-1}}
* you enlist {{dummy XAResource}}
* the business method ends and transaction manager starts with the 2PC
* transaction manager can see there are two XAResources to process, it starts with the first one, transaction manager calls {{ejb remote XAResource.prepare}} while there was no data manipulation (or no XAResource enlisted) at the {{server-2}} (as all work was done in a new transaction) thus the correct return code {{TwoPhaseOutcome.PREPARE_READONLY)}} is returned
* the transaction manager wants to run {{dummy XAResource.prepare}} but it can it's in fact the first and only resource at the list (the previous one was skipped). There are no other resources thus 1PC is applied and the {{dummy XAResource}} is just committed.
On the other hand in case if {{dummy XAResource}} is in order as the first participant the transaction manager can see there are two resources in the 2PC to process thus it has to call {{prepare}} on the first one and the {{dummy XAResource}} is prepared. Then the other resource {{ejb remote XAResource}} returns {{TwoPhaseOutcome.PREPARE_READONLY}} but the {{dummy}} one is already prepared.
Anyway I would consider this as expected.
was (Author: ochaloup):
I've just checked the issue and I would mark it as expected behavior in a way.
First you I would expect that you will get the 1PC behavior if you switch the order of the operation in your bean at the {{server-1}}. If you: first call {{server-2}} and then enlist the {{dummy XAResource}} then you should observe the 1PC behaviour.
In case that you first enlist the {{dummy XAResource}} and you then call the {{server-2}} then you will observe the 2PC behaviour.
The transaction manager is not capable to decide what will be result of the operation while calling from server one to server two. The scenario is like
* you call from {{server-1}} to {{server-2}}
* the app server/transaction manager can see you are working with some XAResource (in this case it's a ejb remote call to the {{server-2}}) thus the remote call is enlisted into the transaction
* the {{server-2}} makes some operations (writing data to a database, it can make the operations in a completely new transaction too ({{REQUIRES_NEW}}) but the {{server-1}} does not know if there were some actions provided or not up to the time the {{prepare}} call is run at the {{ejb remote XAResoruce}} at the {{server-1}}
* you enlist {{dummy XAResource}}
* the business method ends and transaction manager starts with the 2PC
* transaction manager can see there are two XAResources to process, it starts with the first one, transaction manager calls {{ejb remote XAResource.prepare}} while there was no data manipulation (or no XAResource enlisted) at the {{server-2}} (as all work was done in a new transaction) thus the correct return code {{TwoPhaseOutcome.PREPARE_READONLY)}} is returned
* the transaction manager wants to run {{dummy XAResource.prepare}} but it can it's in fact the first and only resource at the list (the previous one was skipped). There are no other resources thus 1PC is applied and the {{dummy XAResource}} is just committed.
On the other hand in case if {{dummy XAResource}} is in order as the first participant the transaction manager can see there are two resources in the 2PC to process thus it has to call {{prepare}} on the first one and the {{dummy XAResource}} is prepared. Then the other resource {{ejb remote XAResource}} returns {{TwoPhaseOutcome.PREPARE_READONLY}} but the {{dummy}} one is already prepared.
Anyway I would consider this as expected.
> Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-10258
> URL: https://issues.jboss.org/browse/WFLY-10258
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 12.0.0.Final
> Reporter: Jörg Bäsner
>
> Scenario:
> - server-1 (intermediary)
> -- Running standalone profile
> -- Has a remote-outbound-connection pointing at server-2 through server-2's public IP address
> -- Intermediary bean need to lookup the Target bean in server-2 and also inject the {{TransactionManager}}
> -- Intermediary bean need to enlist a _dummy_ XAResource
> - server-2 (target)
> -- disable {{JBOSS-LOCAL-USER}} auth
> -- Target bean needs to be annotated with {{@REQUIRES_NEW}} (important)
> - Standalone EJB client invokes an intermediary bean server-1, which as a result invokes target bean on server-2.
> The _dummy_ XAResource should log in the {{commit}} method whether one-phase optimization is being used like:
> {code}
> @Override
> public void commit(Xid arg0, boolean onePhaseOptim) throws XAException {
> logger.info("-- Committing in the client resource. One-phase optimisation is: " + onePhaseOptim + " --"
> + (onePhaseOptim ? "" : " -> TWO-PHASE COMMIT !!!"));
> }
> {code}
> In this scenario it is expected that the one-phase optimization is being used!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10258) Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka edited comment on WFLY-10258 at 4/19/18 8:48 AM:
-----------------------------------------------------------------
I've just checked the issue and I would mark it as expected behavior in a way.
First you I would expect that you will get the 1PC behavior if you switch the order of the operation in your bean at the {{server-1}}. If you: first call {{server-2}} and then enlist the {{dummy XAResource}} then you should observe the 1PC behaviour.
In case that you first enlist the {{dummy XAResource}} and you then call the {{server-2}} then you will observe the 2PC behaviour.
The transaction manager is not capable to decide what will be result of the operation while calling from server one to server two. The scenario is like
* you call from {{server-1}} to {{server-2}}
* the app server/transaction manager can see you are working with some XAResource (in this case it's a ejb remote call to the {{server-2}}) thus the remote call is enlisted into the transaction
* the {{server-2}} makes some operations (writing data to a database, it can make the operations in a completely new transaction too ({{REQUIRES_NEW}}) but the {{server-1}} does not know if there were some actions provided or not up to the time the {{prepare}} call is run at the {{ejb remote XAResoruce}} at the {{server-1}}
* you enlist {{dummy XAResource}}
* the business method ends and transaction manager starts with the 2PC
* transaction manager can see there are two XAResources to process, it starts with the first one, transaction manager calls {{ejb remote XAResource.prepare}} while there was no data manipulation (or no XAResource enlisted) at the {{server-2}} (as all work was done in a new transaction) thus the correct return code {{TwoPhaseOutcome.PREPARE_READONLY)}} is returned
* the transaction manager wants to run {{dummy XAResource.prepare}} but it can it's in fact the first and only resource at the list (the previous one was skipped). There are no other resources thus 1PC is applied and the {{dummy XAResource}} is just committed.
On the other hand in case if {{dummy XAResource}} is in order as the first participant the transaction manager can see there are two resources in the 2PC to process thus it has to call {{prepare}} on the first one and the {{dummy XAResource}} is prepared. Then the other resource {{ejb remote XAResource}} returns {{TwoPhaseOutcome.PREPARE_READONLY}} but the {{dummy}} one is already prepared.
Anyway I would consider this as expected.
was (Author: ochaloup):
I've just checked the issue and I would mark it as expected behavior in a way.
First you I would expect that you will get the 1PC behavior if you switch the order of the operation in your bean at the {{server-1}}. If you first call the second server and then enlist the dummy {{XAResource}} then you should observe the 1PC behaviour.
In case that you first enlist the dummy XAResource and you then call the second server then you will observe the 2PC behaviour.
The transaction manager is not capable to decide what will be result of the operation while calling from server one to server to. The scenario is like
* you call from {{server-1}} to {{server-2}}
* the app server/transaction manager can see you are working with some XAResource (in this case it's a ejb remote call to the {{server-2}}) thus the remote call is enlisted into the transaction
* the {{server-2}} makes some operations (writing data to a database, it can make the operations in a completely new transaction too ({{REQUIRES_NEW}}) but the {{server-1}} does not know if there were some actions provided or not up to the time the {{prepare}} call is run at the {{ejb remote XAResoruce}} at the {{server-1}}
* you enlist {{dummy XAResource}}
* the business method ends and transaction manager starts with the 2PC
* transaction manager can see there are two XAResources to process, it starts with the first one, transaction manager calls {{ejb remote XAResource.prepare}} while there was no data manipulation (or no XAResource enlisted) at the {{server-2}} (as all work was done in a new transaction) thus the correct return code {{TwoPhaseOutcome.PREPARE_READONLY)}} is returned
* the transaction manager wants to run {{dummy XAResource.prepare}} but it can it's in fact the first and only resource at the list (the previous one was skipped). There are no other resources thus 1PC is applied and the {{dummy XAResource}} is just committed.
On the other hand in case if {{dummy XAResource}} is in order as the first participant the transaction manager can see there are two resources in the 2PC to process thus it has to call {{prepare}} on the first one and the {{dummy XAResource}} is prepared. Then the other resource {{ejb remote XAResource}} returns {{TwoPhaseOutcome.PREPARE_READONLY}} but the {{dummy}} one is already prepared.
Anyway I would consider this as expected.
> Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-10258
> URL: https://issues.jboss.org/browse/WFLY-10258
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 12.0.0.Final
> Reporter: Jörg Bäsner
>
> Scenario:
> - server-1 (intermediary)
> -- Running standalone profile
> -- Has a remote-outbound-connection pointing at server-2 through server-2's public IP address
> -- Intermediary bean need to lookup the Target bean in server-2 and also inject the {{TransactionManager}}
> -- Intermediary bean need to enlist a _dummy_ XAResource
> - server-2 (target)
> -- disable {{JBOSS-LOCAL-USER}} auth
> -- Target bean needs to be annotated with {{@REQUIRES_NEW}} (important)
> - Standalone EJB client invokes an intermediary bean server-1, which as a result invokes target bean on server-2.
> The _dummy_ XAResource should log in the {{commit}} method whether one-phase optimization is being used like:
> {code}
> @Override
> public void commit(Xid arg0, boolean onePhaseOptim) throws XAException {
> logger.info("-- Committing in the client resource. One-phase optimisation is: " + onePhaseOptim + " --"
> + (onePhaseOptim ? "" : " -> TWO-PHASE COMMIT !!!"));
> }
> {code}
> In this scenario it is expected that the one-phase optimization is being used!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (SWSQE-145) Modularize CI/CD Pipline
by Jeeva Kandasamy (JIRA)
[ https://issues.jboss.org/browse/SWSQE-145?page=com.atlassian.jira.plugin.... ]
Jeeva Kandasamy edited comment on SWSQE-145 at 4/19/18 8:48 AM:
----------------------------------------------------------------
[~gbaufake] The proposed design looks good.
I have a question on Test runs.
* On step-4 we create traffic and on step-5 we execute our tests
* I guess traffic data will be random
* *If yes,*
* In this approach Test will not know about traffic information
* How can we validate Kiali with generated traffic on test phase?
* *If no,*
* When we follow static data all the time, There is a possibility to miss bugs
My personal opinion, we should have some easy mechanism, to trigger traffic(with defined parameters -> will be used to validate kiali) from test side(at least for integration tests).
was (Author: jkandasa):
[~gbaufake] The proposed design looks good.
I have a question on Test runs.
* On step-4 we create traffic and on step-5 we execute our tests
* I guess traffic data will be random
# If yes,
* In this approach Test will not know about traffic information
* How can we validate Kiali with generated traffic on test phase?
# If no,
* When we follow static data all the time, There is a possibility to miss bugs
My personal opinion, we should have some easy mechanism, to trigger traffic(with defined parameters -> will be used to validate kiali) from test side(at least for integration tests).
> Modularize CI/CD Pipline
> ------------------------
>
> Key: SWSQE-145
> URL: https://issues.jboss.org/browse/SWSQE-145
> Project: Kiali QE
> Issue Type: Epic
> Reporter: Matt Mahoney
> Assignee: Guilherme Baufaker Rêgo
> Attachments: Kiali Pipeline Proposal.png
>
>
> The CI/CD pipeline has become more complex and challenging with which to build CI/CD usage-cases and to add new functionality:
> Use Case Examples:
> 1) Deploy Istio -> Deploy&build-kiali -> Deploy All Service Meshes -> Deploy Traffic Generator on all Service Meshes -> Run all test suites
> 2) Deploy built Kiali -> Run REST suite
> 3) Build and Deploy Kiali -> Run all test suites
> 4) Run UI suite on any Openshift Cluster
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10258) Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka edited comment on WFLY-10258 at 4/19/18 8:47 AM:
-----------------------------------------------------------------
I've just checked the issue and I would mark it as expected behavior in a way.
First you I would expect that you will get the 1PC behavior if you switch the order of the operation in your bean at the {{server-1}}. If you first call the second server and then enlist the dummy {{XAResource}} then you should observe the 1PC behaviour.
In case that you first enlist the dummy XAResource and you then call the second server then you will observe the 2PC behaviour.
The transaction manager is not capable to decide what will be result of the operation while calling from server one to server to. The scenario is like
* you call from {{server-1}} to {{server-2}}
* the app server/transaction manager can see you are working with some XAResource (in this case it's a ejb remote call to the {{server-2}}) thus the remote call is enlisted into the transaction
* the {{server-2}} makes some operations (writing data to a database, it can make the operations in a completely new transaction too ({{REQUIRES_NEW}}) but the {{server-1}} does not know if there were some actions provided or not up to the time the {{prepare}} call is run at the {{ejb remote XAResoruce}} at the {{server-1}}
* you enlist {{dummy XAResource}}
* the business method ends and transaction manager starts with the 2PC
* transaction manager can see there are two XAResources to process, it starts with the first one, transaction manager calls {{ejb remote XAResource.prepare}} while there was no data manipulation (or no XAResource enlisted) at the {{server-2}} (as all work was done in a new transaction) thus the correct return code {{TwoPhaseOutcome.PREPARE_READONLY)}} is returned
* the transaction manager wants to run {{dummy XAResource.prepare}} but it can it's in fact the first and only resource at the list (the previous one was skipped). There are no other resources thus 1PC is applied and the {{dummy XAResource}} is just committed.
On the other hand in case if {{dummy XAResource}} is in order as the first participant the transaction manager can see there are two resources in the 2PC to process thus it has to call {{prepare}} on the first one and the {{dummy XAResource}} is prepared. Then the other resource {{ejb remote XAResource}} returns {{TwoPhaseOutcome.PREPARE_READONLY}} but the {{dummy}} one is already prepared.
Anyway I would consider this as expected.
was (Author: ochaloup):
I have been investigating on the issue and I would mark it as expected behavior in a way.
First you I would expect that you will get the 1PC behavior if you switch the order of the operation in your bean at the {{server-1}}. If you first call the second server and then enlist the dummy {{XAResource}} then you should observe the 1PC behaviour.
In case that you first enlist the dummy XAResource and you then call the second server then you will observe the 2PC behaviour.
The transaction manager is not capable to decide what will be result of the operation while calling from server one to server to. The scenario is like
* you call from {{server-1}} to {{server-2}}
* the app server/transaction manager can see you are working with some XAResource (in this case it's a ejb remote call to the {{server-2}}) thus the remote call is enlisted into the transaction
* the {{server-2}} makes some operations (writing data to a database, it can make the operations in a completely new transaction too ({{REQUIRES_NEW}}) but the {{server-1}} does not know if there were some actions provided or not up to the time the {{prepare}} call is run at the {{ejb remote XAResoruce}} at the {{server-1}}
* you enlist {{dummy XAResource}}
* the business method ends and transaction manager starts with the 2PC
* transaction manager can see there are two XAResources to process, it starts with the first one, transaction manager calls {{ejb remote XAResource.prepare}} while there was no data manipulation (or no XAResource enlisted) at the {{server-2}} (as all work was done in a new transaction) thus the correct return code {{TwoPhaseOutcome.PREPARE_READONLY)}} is returned
* the transaction manager wants to run {{dummy XAResource.prepare}} but it can it's in fact the first and only resource at the list (the previous one was skipped). There are no other resources thus 1PC is applied and the {{dummy XAResource}} is just committed.
On the other hand in case if {{dummy XAResource}} is in order as the first participant the transaction manager can see there are two resources in the 2PC to process thus it has to call {{prepare}} on the first one and the {{dummy XAResource}} is prepared. Then the other resource {{ejb remote XAResource}} returns {{TwoPhaseOutcome.PREPARE_READONLY}} but the {{dummy}} one is already prepared.
Anyway I would consider this as expected.
> Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-10258
> URL: https://issues.jboss.org/browse/WFLY-10258
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 12.0.0.Final
> Reporter: Jörg Bäsner
>
> Scenario:
> - server-1 (intermediary)
> -- Running standalone profile
> -- Has a remote-outbound-connection pointing at server-2 through server-2's public IP address
> -- Intermediary bean need to lookup the Target bean in server-2 and also inject the {{TransactionManager}}
> -- Intermediary bean need to enlist a _dummy_ XAResource
> - server-2 (target)
> -- disable {{JBOSS-LOCAL-USER}} auth
> -- Target bean needs to be annotated with {{@REQUIRES_NEW}} (important)
> - Standalone EJB client invokes an intermediary bean server-1, which as a result invokes target bean on server-2.
> The _dummy_ XAResource should log in the {{commit}} method whether one-phase optimization is being used like:
> {code}
> @Override
> public void commit(Xid arg0, boolean onePhaseOptim) throws XAException {
> logger.info("-- Committing in the client resource. One-phase optimisation is: " + onePhaseOptim + " --"
> + (onePhaseOptim ? "" : " -> TWO-PHASE COMMIT !!!"));
> }
> {code}
> In this scenario it is expected that the one-phase optimization is being used!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (SWSQE-145) Modularize CI/CD Pipline
by Jeeva Kandasamy (JIRA)
[ https://issues.jboss.org/browse/SWSQE-145?page=com.atlassian.jira.plugin.... ]
Jeeva Kandasamy commented on SWSQE-145:
---------------------------------------
[~gbaufake] The proposed design looks good.
I have a question on Test runs.
* On step-4 we create traffic and on step-5 we execute our tests
* I guess traffic data will be random
# If yes,
* In this approach Test will not know about traffic information
* How can we validate Kiali with generated traffic on test phase?
# If no,
* When we follow static data all the time, There is a possibility to miss bugs
My personal opinion, we should have some easy mechanism, to trigger traffic(with defined parameters -> will be used to validate kiali) from test side(at least for integration tests).
> Modularize CI/CD Pipline
> ------------------------
>
> Key: SWSQE-145
> URL: https://issues.jboss.org/browse/SWSQE-145
> Project: Kiali QE
> Issue Type: Epic
> Reporter: Matt Mahoney
> Assignee: Guilherme Baufaker Rêgo
> Attachments: Kiali Pipeline Proposal.png
>
>
> The CI/CD pipeline has become more complex and challenging with which to build CI/CD usage-cases and to add new functionality:
> Use Case Examples:
> 1) Deploy Istio -> Deploy&build-kiali -> Deploy All Service Meshes -> Deploy Traffic Generator on all Service Meshes -> Run all test suites
> 2) Deploy built Kiali -> Run REST suite
> 3) Build and Deploy Kiali -> Run all test suites
> 4) Run UI suite on any Openshift Cluster
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10258) Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-10258:
----------------------------------------
I have been investigating on the issue and I would mark it as expected behavior in a way.
First you I would expect that you will get the 1PC behavior if you switch the order of the operation in your bean at the {{server-1}}. If you first call the second server and then enlist the dummy {{XAResource}} then you should observe the 1PC behaviour.
In case that you first enlist the dummy XAResource and you then call the second server then you will observe the 2PC behaviour.
The transaction manager is not capable to decide what will be result of the operation while calling from server one to server to. The scenario is like
* you call from {{server-1}} to {{server-2}}
* the app server/transaction manager can see you are working with some XAResource (in this case it's a ejb remote call to the {{server-2}}) thus the remote call is enlisted into the transaction
* the {{server-2}} makes some operations (writing data to a database, it can make the operations in a completely new transaction too ({{REQUIRES_NEW}}) but the {{server-1}} does not know if there were some actions provided or not up to the time the {{prepare}} call is run at the {{ejb remote XAResoruce}} at the {{server-1}}
* you enlist {{dummy XAResource}}
* the business method ends and transaction manager starts with the 2PC
* transaction manager can see there are two XAResources to process, it starts with the first one, transaction manager calls {{ejb remote XAResource.prepare}} while there was no data manipulation (or no XAResource enlisted) at the {{server-2}} (as all work was done in a new transaction) thus the correct return code {{TwoPhaseOutcome.PREPARE_READONLY)}} is returned
* the transaction manager wants to run {{dummy XAResource.prepare}} but it can it's in fact the first and only resource at the list (the previous one was skipped). There are no other resources thus 1PC is applied and the {{dummy XAResource}} is just committed.
On the other hand in case if {{dummy XAResource}} is in order as the first participant the transaction manager can see there are two resources in the 2PC to process thus it has to call {{prepare}} on the first one and the {{dummy XAResource}} is prepared. Then the other resource {{ejb remote XAResource}} returns {{TwoPhaseOutcome.PREPARE_READONLY}} but the {{dummy}} one is already prepared.
Anyway I would consider this as expected.
> Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-10258
> URL: https://issues.jboss.org/browse/WFLY-10258
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 12.0.0.Final
> Reporter: Jörg Bäsner
>
> Scenario:
> - server-1 (intermediary)
> -- Running standalone profile
> -- Has a remote-outbound-connection pointing at server-2 through server-2's public IP address
> -- Intermediary bean need to lookup the Target bean in server-2 and also inject the {{TransactionManager}}
> -- Intermediary bean need to enlist a _dummy_ XAResource
> - server-2 (target)
> -- disable {{JBOSS-LOCAL-USER}} auth
> -- Target bean needs to be annotated with {{@REQUIRES_NEW}} (important)
> - Standalone EJB client invokes an intermediary bean server-1, which as a result invokes target bean on server-2.
> The _dummy_ XAResource should log in the {{commit}} method whether one-phase optimization is being used like:
> {code}
> @Override
> public void commit(Xid arg0, boolean onePhaseOptim) throws XAException {
> logger.info("-- Committing in the client resource. One-phase optimisation is: " + onePhaseOptim + " --"
> + (onePhaseOptim ? "" : " -> TWO-PHASE COMMIT !!!"));
> }
> {code}
> In this scenario it is expected that the one-phase optimization is being used!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years