[JBoss JIRA] (AG-72) New FlushMode FILL
by Luis Barreiro (JIRA)
Luis Barreiro created AG-72:
-------------------------------
Summary: New FlushMode FILL
Key: AG-72
URL: https://issues.jboss.org/browse/AG-72
Project: Agroal
Issue Type: Enhancement
Components: pool
Affects Versions: 0.4
Reporter: Luis Barreiro
Assignee: Luis Barreiro
Fix For: 0.5
This new mode is to be called after an increasse in min-size, so that the pool creates the necessary connections.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (AG-71) Warnings on DataSource.close()
by Luis Barreiro (JIRA)
Luis Barreiro created AG-71:
-------------------------------
Summary: Warnings on DataSource.close()
Key: AG-71
URL: https://issues.jboss.org/browse/AG-71
Project: Agroal
Issue Type: Bug
Components: pool
Affects Versions: 0.4
Reporter: Luis Barreiro
Assignee: Luis Barreiro
Fix For: 0.5
SQLException: "Closing connection in incorrect state"
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10258) Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin... ]
David Lloyd updated WFLY-10258:
-------------------------------
Forum Reference: https://developer.jboss.org/message/982097
> 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, 3 months
[JBoss JIRA] (WFLY-10258) Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin... ]
David Lloyd edited comment on WFLY-10258 at 4/19/18 10:40 AM:
--------------------------------------------------------------
[~ochaloup] Hmm good points. I wonder if there's some way we could improve it though. What if we proactively delisted the resource with TMSUCCESS before prepare begins? Will the TM still try to include it in commit processing?
More generally: is there a way to indicate that a resource _will_ return {{XA_RDONLY}} when prepare is called, ahead of time? It seems like {{XAResource.end()}} should have had a supported return value where the resource could indicate that it hadn't done anything.
was (Author: dmlloyd):
[~ochaloup] Hmm good points. I wonder if there's some way we could improve it though. What if we proactively delisted the resource with TMSUCCESS before prepare begins? Will the TM still try to include it in commit processing?
> 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, 3 months
[JBoss JIRA] (WFLY-10109) [Artemis 2.x upgrade] MDB connected to remote server does not get activated when using discovery group with JGroups
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10109?page=com.atlassian.jira.plugin... ]
Erich Duda commented on WFLY-10109:
-----------------------------------
[~jmesnil] I've tried to run it on Jenkins and I think that I reproduced the issue, see \[1\]. You can find all logs in the job.
\[1\] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eduda-verifier...
> [Artemis 2.x upgrade] MDB connected to remote server does not get activated when using discovery group with JGroups
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10109
> URL: https://issues.jboss.org/browse/WFLY-10109
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: log
>
>
> Sometimes happens that MDB does not start to consume messages from remote server. There are not warning or error messages in log.
> Test Scenario:
> * Start server with deployed InQueue and OutQueue
> * Start 2nd server with configured pooled-connection-factory to connect to 1st server
> * Deploy MDB to 2nd server - mdb is consuming messages from InQueue and sending to OutQueue
> * Start sending messages to InQueue to 1st server
> * Let MDB processing messages from InQueue
> * Start consuming messages from OutQueue from 1st server
> Pass Criteria: There is the same number of sent and received messages
> Actual Result: Sometimes happens that Mdb does not start to consume messages.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (SWSQE-145) Modularize CI/CD Pipline
by Matt Mahoney (JIRA)
[ https://issues.jboss.org/browse/SWSQE-145?page=com.atlassian.jira.plugin.... ]
Matt Mahoney commented on SWSQE-145:
------------------------------------
There will be, and are now, test cases that depend on traffic being generating while the test is running.
For example, Service Graph & Json test cases will validate Edge color, Traffic throughput, Error rates, etc. If the traffic stopped prior to running the tests, then the expected throughput/Error-rates/Edge-colors may not be as expected, and thus potentially causing false failures.
Modurlarizing the pipeline allows us much flexibility on how we want to build the needed scenarios, perhaps we need to consider a bit more about how we will build those scenarios (i.e. various Jenkins pipeline jobs for needed scenarios or one master pipeline job with tunable parameters for controlling traffic/mesh-deployments/suites-to-be-run/etc or a combination thereof)?
> 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, 3 months
[JBoss JIRA] (AG-69) Pool-less mode
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/AG-69?page=com.atlassian.jira.plugin.syst... ]
Jesper Pedersen commented on AG-69:
-----------------------------------
It is more for scenarios where services are kept warm in order to lower their startup penalty. Think 400 warm services against a data source that only supports 100 connections. Of course 300 will run into the blocking timeout issue once activated, but that is another problem.
> Pool-less mode
> --------------
>
> Key: AG-69
> URL: https://issues.jboss.org/browse/AG-69
> Project: Agroal
> Issue Type: Feature Request
> Components: pool
> Reporter: Jesper Pedersen
> Assignee: Luis Barreiro
>
> In scenarios where multiple pools access the same data source instance you may end up in a situation where the combined number of max-pool-size is greater than the maximum number of connections in the data source.
> Introduce a pool-less mode, where the underlying connection is closed upon return to the pool if the pool size is greater than min-pool-size.
> This will allow you to configure Agroal to
> {{.mode("pool-less").minSize(0).maxSize(1)}}
> that only use 1 connection that is returned upon close. This is especially useful for service-mesh scenarios where each service is short-lived, and process one transaction.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months