[JBoss JIRA] (WFLY-13238) Object returned by HttpSession.getAttribute(...) following a previous setAttribute(...), not mutating correctly on non-primary owner using ATTRIBUTE granularity when cache is non-transactional.
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13238?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13238:
--------------------------------
Description:
Consider the following:
{code:java}
session.setAttribute("foo", new AtomicInteger(0));
AtomicInteger value = (AtomicInteger) session.getAttribute("foo");
value.incrementAndGet();
{code}
When request is receive on a non-primary owner, the above code does not correctly replicate the mutated value when using ATTRIBUTE granularity and the backing cache in non-transactional.
was:
Consider the following:
{code:java}
session.setAttribute("foo", new AtomicInteger(0));
AtomicInteger value = (AtomicInteger) session.getAttribute("foo");
value.incrementAndGet();
{code}
When t
> Object returned by HttpSession.getAttribute(...) following a previous setAttribute(...), not mutating correctly on non-primary owner using ATTRIBUTE granularity when cache is non-transactional.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13238
> URL: https://issues.redhat.com/browse/WFLY-13238
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 19.0.0.Beta3
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
>
> Consider the following:
> {code:java}
> session.setAttribute("foo", new AtomicInteger(0));
> AtomicInteger value = (AtomicInteger) session.getAttribute("foo");
> value.incrementAndGet();
> {code}
> When request is receive on a non-primary owner, the above code does not correctly replicate the mutated value when using ATTRIBUTE granularity and the backing cache in non-transactional.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13144) Resource Adapter can't be deleted after restarting server
by Ivo Studensky (Jira)
[ https://issues.redhat.com/browse/WFLY-13144?page=com.atlassian.jira.plugi... ]
Ivo Studensky reassigned WFLY-13144:
------------------------------------
Assignee: Ivo Studensky (was: Stefano Maestri)
> Resource Adapter can't be deleted after restarting server
> ---------------------------------------------------------
>
> Key: WFLY-13144
> URL: https://issues.redhat.com/browse/WFLY-13144
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 14.0.1.Final, 11.0.0.Final, 17.0.1.Final
> Reporter: Dmitrii Pogorelov
> Assignee: Ivo Studensky
> Priority: Major
> Attachments: jca-demo-1.0.rar, jcademo-source-code.rar
>
>
> The issue is related to the WFLY-6774 issue. I'm working with Teiid and should create/delete resource adapters many times, especially resource adapters based on the same archive. The WFLY-6774 fix works well before the restarting server allowing me to create/delete resource adapters without restarting the server. Once I restart the server and try to remove a resource adapter based on an archive I'll get the following error:
> {code:noformat}
> [standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL",
> "rolled-back" => true
> }
> {code}
> After showing the error server will rollback the "remove" command deploying the jca-demo-1.0.rar archive again and re-creating the jcaDemo_VDB_ID_1 resource adapter. As a result I can't remove the resource adapter via cli commands, it can be removed only manually (removing the resource adapter in standalone.xml). The bug can be reproduced (at least versions which I checked) on WildFly 11.0.0.Final, WildFly 14.0.1.Final and WildFly 17.0.1.Final.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-5161) Move doughnut chart popup to the left to see the contnt
by Anna Dupliak (Jira)
Anna Dupliak created DROOLS-5161:
------------------------------------
Summary: Move doughnut chart popup to the left to see the contnt
Key: DROOLS-5161
URL: https://issues.redhat.com/browse/DROOLS-5161
Project: Drools
Issue Type: Enhancement
Components: Scenario Simulation and Testing
Affects Versions: 7.34.0.Final
Reporter: Anna Dupliak
Assignee: Yeser Amer
Attachments: CoveragePopup.webm
When user navigate on doughnut chat there is a popup that gets the idea how many rules/decisions covered. But since it is always righter then the mouse pointer and the chart has right adjustment - the popup data is hidden every time.
See: [^CoveragePopup.webm]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (SWSQE-1094) Use 1.0 and 1.1 channels for service mesh subscriptions
by Filip Brychta (Jira)
[ https://issues.redhat.com/browse/SWSQE-1094?page=com.atlassian.jira.plugi... ]
Filip Brychta updated SWSQE-1094:
---------------------------------
Summary: Use 1.0 and 1.1 channels for service mesh subscriptions (was: Use channels for service mesh subscriptions)
> Use 1.0 and 1.1 channels for service mesh subscriptions
> -------------------------------------------------------
>
> Key: SWSQE-1094
> URL: https://issues.redhat.com/browse/SWSQE-1094
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Filip Brychta
> Assignee: Filip Brychta
> Priority: Major
> Labels: infrastructure
>
> Changes in service mesh channels:
> To allow multiple versions of the olm metadata, I uploaded the 1.0.9 manifest to a channel named "1.0" and uploaded the 1.1.0 manifest to a channel named "1.1".
> When 1.0.10 build is ready, it can be uploaded to the "1.0" channel replacing the 1.0.9.
> Eventually, when we get the 1.1.0 RC1 build, I can upload it to the "stable" channel (since the stable channel will be the default channel after 1.1 release).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (SWSQE-1094) Use 1.0 and 1.1 channels for service mesh subscriptions
by Filip Brychta (Jira)
[ https://issues.redhat.com/browse/SWSQE-1094?page=com.atlassian.jira.plugi... ]
Filip Brychta resolved SWSQE-1094.
----------------------------------
Resolution: Done
> Use 1.0 and 1.1 channels for service mesh subscriptions
> -------------------------------------------------------
>
> Key: SWSQE-1094
> URL: https://issues.redhat.com/browse/SWSQE-1094
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Filip Brychta
> Assignee: Filip Brychta
> Priority: Major
> Labels: infrastructure
>
> Changes in service mesh channels:
> To allow multiple versions of the olm metadata, I uploaded the 1.0.9 manifest to a channel named "1.0" and uploaded the 1.1.0 manifest to a channel named "1.1".
> When 1.0.10 build is ready, it can be uploaded to the "1.0" channel replacing the 1.0.9.
> Eventually, when we get the 1.1.0 RC1 build, I can upload it to the "stable" channel (since the stable channel will be the default channel after 1.1 release).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (SWSQE-1094) Use channels for service mesh subscriptions
by Filip Brychta (Jira)
Filip Brychta created SWSQE-1094:
------------------------------------
Summary: Use channels for service mesh subscriptions
Key: SWSQE-1094
URL: https://issues.redhat.com/browse/SWSQE-1094
Project: Kiali QE
Issue Type: QE Task
Reporter: Filip Brychta
Assignee: Filip Brychta
Changes in service mesh channels:
To allow multiple versions of the olm metadata, I uploaded the 1.0.9 manifest to a channel named "1.0" and uploaded the 1.1.0 manifest to a channel named "1.1".
When 1.0.10 build is ready, it can be uploaded to the "1.0" channel replacing the 1.0.9.
Eventually, when we get the 1.1.0 RC1 build, I can upload it to the "stable" channel (since the stable channel will be the default channel after 1.1 release).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months