[JBoss JIRA] (WFLY-8579) Topic messages are sent to all shared non-durable subscription participants
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8579?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-8579:
-----------------------------------
Note that JSR 343, 8.3.2 Shared non-durable subscriptions applies to regular JMS client, not to MDBs.
In 13.1, MDB activation properties, it is written that:
.bq subscriptionName - This property only applies to endpoints (message-driven beans) that receive messages published to a topic. It may be used to specify the name of the durable or non-durable subscription. It is not defined whether a shared or unshared subscription is used.
Could you try to add the activation config property:
{code}
@ActivationConfigProperty(propertyName = "shareSubscriptions", propertyValue = "true")
{code}
to ensure that a shared subscription is used?
> Topic messages are sent to all shared non-durable subscription participants
> ---------------------------------------------------------------------------
>
> Key: WFLY-8579
> URL: https://issues.jboss.org/browse/WFLY-8579
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Scott Van Wart
> Assignee: Jeff Mesnil
> Attachments: duplicate-shared.zip
>
>
> I have two MDBs with a subscription to a topic. The same clientId and a subscriptionName are specified in the activation config properties for each MDB. subscriptionDurability is omitted (defaulted to NonDurable).
> When I send a single message to this topic, both MDBs receive the message. According to JSR 343, 8.3.2 Shared non-durable subscriptions:
> bq. A non-durable shared subscription is used by a client that needs to be able to
> share the work of receiving messages from a non-durable topic subscription
> amongst multiple consumers. A non-durable shared subscription may
> therefore have more than one consumer. *Each message from the subscription will be delivered to only one of the consumers on that
> subscription.*
> Setting the subscriptionDurability property to Durable works as expected (each message is delivered to only one consumer in that subscription).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8579) Topic messages are sent to all shared non-durable subscription participants
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8579?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil edited comment on WFLY-8579 at 4/14/17 6:39 AM:
------------------------------------------------------------
Note that JSR 343, 8.3.2 Shared non-durable subscriptions applies to regular JMS client, not to MDBs.
In 13.1, MDB activation properties, it is written that:
{quote}subscriptionName - This property only applies to endpoints (message-driven beans) that receive messages published to a topic. It may be used to specify the name of the durable or non-durable subscription. It is not defined whether a shared or unshared subscription is used.
{quote}
Could you try to add the activation config property:
{code}
@ActivationConfigProperty(propertyName = "shareSubscriptions", propertyValue = "true")
{code}
to ensure that a shared subscription is used?
was (Author: jmesnil):
Note that JSR 343, 8.3.2 Shared non-durable subscriptions applies to regular JMS client, not to MDBs.
In 13.1, MDB activation properties, it is written that:
.bq subscriptionName - This property only applies to endpoints (message-driven beans) that receive messages published to a topic. It may be used to specify the name of the durable or non-durable subscription. It is not defined whether a shared or unshared subscription is used.
Could you try to add the activation config property:
{code}
@ActivationConfigProperty(propertyName = "shareSubscriptions", propertyValue = "true")
{code}
to ensure that a shared subscription is used?
> Topic messages are sent to all shared non-durable subscription participants
> ---------------------------------------------------------------------------
>
> Key: WFLY-8579
> URL: https://issues.jboss.org/browse/WFLY-8579
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Scott Van Wart
> Assignee: Jeff Mesnil
> Attachments: duplicate-shared.zip
>
>
> I have two MDBs with a subscription to a topic. The same clientId and a subscriptionName are specified in the activation config properties for each MDB. subscriptionDurability is omitted (defaulted to NonDurable).
> When I send a single message to this topic, both MDBs receive the message. According to JSR 343, 8.3.2 Shared non-durable subscriptions:
> bq. A non-durable shared subscription is used by a client that needs to be able to
> share the work of receiving messages from a non-durable topic subscription
> amongst multiple consumers. A non-durable shared subscription may
> therefore have more than one consumer. *Each message from the subscription will be delivered to only one of the consumers on that
> subscription.*
> Setting the subscriptionDurability property to Durable works as expected (each message is delivered to only one consumer in that subscription).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8582) Legacy encrypt protocol support is missing a requirement on elytron subsystem
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8582?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-10361 to WFLY-8582:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8582 (was: JBEAP-10361)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR15)
> Legacy encrypt protocol support is missing a requirement on elytron subsystem
> -----------------------------------------------------------------------------
>
> Key: WFLY-8582
> URL: https://issues.jboss.org/browse/WFLY-8582
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Environment: All
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Minor
>
> Can the error message be improved to recognise that not only is there no operation registered at the address, but there is no subsystem registered with that name.
> Example: If ASYM_ENCRYPT is configured, without the elytron subsystem being present, there is a runtime error which doesn't make it obvious how to address the problem.
> Customers porting EAP 7.0.x domain config to EAP 7.1.0 with fix for CVE-2016-2141 will see this
> Runtime Error:
> [Host Controller] 16:21:35,148 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> [Host Controller] ("profile" => "full-ha"),
> [Host Controller] ("subsystem" => "jgroups"),
> [Host Controller] ("stack" => "tcpping"),
> [Host Controller] ("protocol" => "ASYM_ENCRYPT")
> [Host Controller] ]) - failure description: "WFLYCLJG0026: No add operation registered at /profile=full-ha/subsystem=elytron/key-store=jgroups-tcpping"
> [Host Controller] 16:21:35,164 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> [Host Controller] 16:21:35,170 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0178: Aborting with exit code 99
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2674) An attribute that another attribute 'requires' should be allowed to be undefined if another attribute in the same set of 'requires' is an alternative
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2674?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2674:
------------------------------------------
Jeff noted that:
"the case of the deployment 'add' operation 'archive' property is interesting. The 'requires' contains path/hash/empty that are alternatives."
So a question I have is why this isn't failing some CI test with https://github.com/wildfly/wildfly-core/pull/2219, which should be bringing validation to the elements in the 'content' list attribute in deployment resources.
> An attribute that another attribute 'requires' should be allowed to be undefined if another attribute in the same set of 'requires' is an alternative
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2674
> URL: https://issues.jboss.org/browse/WFCORE-2674
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Right now ValidateModelStepHandler checks whether all attributes a defined attribute lists in 'requires' are themselves defined. It ignore the presence of alternatives settings. However in discussion with [~jfdenise] we've concluded that allowing undefined do to any 'alternatives' isn't right either. Rather, for a 'requires' to be superceded by an 'alternatives', only alternatives that are themselves part of the same set of 'requires' are relevant.
> Imagine three scenarios:
> I.
> 1) A requires B, C
> 2) B and C are alternatives to each other
> User configures A and B is ok. Or, user configures A and C is ok. Configuring A, B, C is not ok.
> II.
> 1) A requires B, C
> 2) B and C are alternatives to each other
> 3) B and D are also alternatives
> User configures A and D and therefore must configure C, but not B. Configuring C satisfies the "requires" B.
> III.
> 1) A requires B, C
> 2) B and C are NOT alternatives to each other
> 3) B and D are alternatives
> User configures A therefore cannot configure D, must configure B and C. Configuring D does not satisfy the "requires" B.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2674) An attribute that another attribute 'requires' should be allowed to be undefined if another attribute in the same set of 'requires' is an alternative
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2674:
----------------------------------------
Summary: An attribute that another attribute 'requires' should be allowed to be undefined if another attribute in the same set of 'requires' is an alternative
Key: WFCORE-2674
URL: https://issues.jboss.org/browse/WFCORE-2674
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Right now ValidateModelStepHandler checks whether all attributes a defined attribute lists in 'requires' are themselves defined. It ignore the presence of alternatives settings. However in discussion with [~jfdenise] we've concluded that allowing undefined do to any 'alternatives' isn't right either. Rather, for a 'requires' to be superceded by an 'alternatives', only alternatives that are themselves part of the same set of 'requires' are relevant.
Imagine three scenarios:
I.
1) A requires B, C
2) B and C are alternatives to each other
User configures A and B is ok. Or, user configures A and C is ok. Configuring A, B, C is not ok.
II.
1) A requires B, C
2) B and C are alternatives to each other
3) B and D are also alternatives
User configures A and D and therefore must configure C, but not B. Configuring C satisfies the "requires" B.
III.
1) A requires B, C
2) B and C are NOT alternatives to each other
3) B and D are alternatives
User configures A therefore cannot configure D, must configure B and C. Configuring D does not satisfy the "requires" B.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFLY-8580) Problems in DomainHostExcludes700TestCase
by Ken Wills (JIRA)
Ken Wills created WFLY-8580:
-------------------------------
Summary: Problems in DomainHostExcludes700TestCase
Key: WFLY-8580
URL: https://issues.jboss.org/browse/WFLY-8580
Project: WildFly
Issue Type: Bug
Components: Domain Management
Reporter: Ken Wills
Assignee: Ken Wills
Fix For: 11.0.0.Beta1
The profile clone operation in the new DomainHostExcludes700TestCase.test003PostBootUpdates() in testsuite/mixed-domain fails with the following message:
{code}
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.messaging.activemq.server.default' is already registered in context 'profile=clone'."},
"rolled-back" => true
}
{code}
And we also see an error in
{code}
DomainHostExcludes700TestCase.test001SlaveBoot:45->DomainHostExcludesTest.test001SlaveBoot:217->DomainHostExcludesTest.checkSocketBindingGroups:300 ["full-ha-sockets"] expected:<2> but was:<1>
{code}
Some WIP to create this test is in my https://github.com/kabir/wildfly/tree/WFLY-6616 branch
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (HAWKULARQE-81) Baseline #3
by viet nguyen (JIRA)
[ https://issues.jboss.org/browse/HAWKULARQE-81?page=com.atlassian.jira.plu... ]
viet nguyen edited comment on HAWKULARQE-81 at 4/13/17 12:16 PM:
-----------------------------------------------------------------
*Test setup params:*
* 30 metrics per pod
* 30s collection interval
* Disable heapster
* Defaults 2GB RAM for HMetrics, Cassandra (1node)
* Collect metrics for at least 4 hours. Use [PyMe|https://github.com/vnugent/pyme] to gather Metric IDs and raw data points.
*Expected results:*
# 30 raw data points per Metric ID per 15 minute duration
# 30 Metric IDs /pod * 30 = 900 raw data points per pod per 15min duration (rdp/pod)
# 900 rdp/pod * number of pod = grand total raw data points per 15 min duration
| number of pods| grand total rdp/15min (direct query)|rdp/minute (calculated)|
| 50 | 45,000 |3,000|
|100|90,000|6,000|
|150|135,000|9,000|
|230|207,000|13,800|
*Actual results:*
* 50 pods [^50pods.png]
* 100 pods [^100pods.png]
* 150 pods [^150-2.png]
* 230 pods - Unrecoverable OOM exception in Cassandra when PyMe ran. [BZ1435436|https://bugzilla.redhat.com/show_bug.cgi?id=1435436]
*Observations*:
* Up to 150 pods- all raw metrics from HOSA were correctly captured and stored in Cassandra
* Starting at 100 pods - metric definition query would fail due to timeout exception (HTTP 409). For the query to work all pods must be stopped, ie no new metrics are generate from HOSA.
* At 230 pods metric definition query triggered OOM in Cassandra
* number of raw metrics / minute is substantially less than other internal benchmarks.
was (Author: vietn):
*Test setup params:*
* 30 metrics per pod
* 30s collection interval
* Disable heapster
* Defaults 2GB RAM for HMetrics, Cassandra (1node)
* Collect metrics for at least 4 hours. Use [PyMe|https://github.com/vnugent/pyme] to gather Metric IDs and raw data points.
*Expected results:*
# 30 raw data points per Metric ID per 15 minute duration
# 30 Metric IDs /pod * 30 = 900 raw data points per pod per 15min duration (rdp/pod)
# 900 rdp/pod * number of pod = grand total raw data points per 15 min duration
| number of pods| grand total rdp/15min (direct quer)|rdp/minute (calculated)|
| 50 | 45,000 |3,000|
|100|90,000|6,000|
|150|135,000|9,000|
|230|207,000|13,800|
*Actual results:*
* 50 pods [^50pods.png]
* 100 pods [^100pods.png]
* 150 pods [^150-2.png]
* 230 pods - Unrecoverable OOM exception in Cassandra when PyMe ran. [BZ1435436|https://bugzilla.redhat.com/show_bug.cgi?id=1435436]
*Observations*:
* Up to 150 pods- all raw metrics from HOSA were correctly captured and stored in Cassandra
* Starting at 100 pods - metric definition query would fail due to timeout exception (HTTP 409). For the query to work all pods must be stopped, ie no new metrics are generate from HOSA.
* At 230 pods metric definition query triggered OOM in Cassandra
* number of raw metrics / minute is substantially less than other internal benchmarks.
> Baseline #3
> -----------
>
> Key: HAWKULARQE-81
> URL: https://issues.jboss.org/browse/HAWKULARQE-81
> Project: Hawkular QE
> Issue Type: Sub-task
> Reporter: viet nguyen
> Assignee: viet nguyen
> Attachments: 100pods.png, 150-2.png, 50pods.png, March28_0200_raw.zip, promgen-analytic-12hr.png
>
>
> * Run pyme on master to eliminate vpn slowness
> * Fix query start-end window
> * Update pyme endpoint to increase metrics to 30 (currently 2)
> * insert metrics tallies into a separate Hawkular Metrics instance and use Grafana as a visual tool
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month