[JBoss JIRA] (JGRP-1939) UDP Max Bundling size setting is treated as max allowable packet size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1939?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1939.
----------------------------
Resolution: Done
> UDP Max Bundling size setting is treated as max allowable packet size
> ---------------------------------------------------------------------
>
> Key: JGRP-1939
> URL: https://issues.jboss.org/browse/JGRP-1939
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.5
> Reporter: Jim Thomas
> Assignee: Bela Ban
> Fix For: 3.6.5
>
>
> When the maximum bundle size is exceeded by a non-bundled message an error is generated and the message is not set. When bundling is configured to small sizes this is very problematic because it is impossible to avoid without serious performance consequences.
> JGRP000029: node1: failed sending message to node2 (1413 bytes): java.lang.Exception: message size (1413) is greater than max bundling size (1400). Set the fragmentation/bundle size in FRAG/FRAG2 and TP correctly, headers: FRAG: [id=999, frag_id=1, num_frags=3], UDP: [cluster_name=MainCluster]
> Recommendation: Let bundling size limit be just that -- the maximum size that bundles will be built to. If a maximum UDP packet size restriction is desired then add that as a separate option. However I don't recommend this because this error is pretty much fatal if the wrong kind of message is exceeding the limit. Once the packet has made it past the frag protocols it is going to be the size it wants to be. Refusing to put it on the network only has bad outcomes because there is no recovery.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-861) Wrong installation date in product info report
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-861?page=com.atlassian.jira.plugin... ]
Marek Kopecký updated WFCORE-861:
---------------------------------
Description:
*Description of problem:*
Product info report shows wrong installation date in wildfly. Reported installation date is date of wildfly building.
*How reproducible:*
Always on EAP from zip installation
*Steps to Reproduce:*
# get fresh wildfly from git
# build wildfly
# ./standalone.sh
# ./jboss-cli.sh -c
# :product-info
*Actual results:*
installation-date is a date of wildfly building
*Expected results:*
If Product Install Date is not available, wildfly do not report it.
*Additional info:*
Installation date is reported correctly, when installer is used.
was:
*Description of problem:*
Product info report shows wrong installation date in EAP from zip installation. Reported installation date is date of EAP building.
*How reproducible:*
Always on EAP from zip installation
*Steps to Reproduce:*
# get fresh EAP from zip
# ./standalone.sh
# ./jboss-cli.sh -c
# :product-info
*Actual results:*
installation-date is a date of EAP building
*Expected results:*
If Product Install Date is not available in zip installation, EAP do not report it.
*Additional info:*
Installation date is reported correctly, when installer is used.
> Wrong installation date in product info report
> ----------------------------------------------
>
> Key: WFCORE-861
> URL: https://issues.jboss.org/browse/WFCORE-861
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Alpha11
> Reporter: Marek Kopecký
> Assignee: ehsavoie Hugonnet
>
> *Description of problem:*
> Product info report shows wrong installation date in wildfly. Reported installation date is date of wildfly building.
> *How reproducible:*
> Always on EAP from zip installation
> *Steps to Reproduce:*
> # get fresh wildfly from git
> # build wildfly
> # ./standalone.sh
> # ./jboss-cli.sh -c
> # :product-info
> *Actual results:*
> installation-date is a date of wildfly building
> *Expected results:*
> If Product Install Date is not available, wildfly do not report it.
> *Additional info:*
> Installation date is reported correctly, when installer is used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (JGRP-1939) UDP Max Bundling size setting is treated as max allowable packet size
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1939?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1939:
--------------------------------
Makes sense, fixed this in 3.6.5. Running the test suite now.
> UDP Max Bundling size setting is treated as max allowable packet size
> ---------------------------------------------------------------------
>
> Key: JGRP-1939
> URL: https://issues.jboss.org/browse/JGRP-1939
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.5
> Reporter: Jim Thomas
> Assignee: Bela Ban
> Fix For: 3.6.5
>
>
> When the maximum bundle size is exceeded by a non-bundled message an error is generated and the message is not set. When bundling is configured to small sizes this is very problematic because it is impossible to avoid without serious performance consequences.
> JGRP000029: node1: failed sending message to node2 (1413 bytes): java.lang.Exception: message size (1413) is greater than max bundling size (1400). Set the fragmentation/bundle size in FRAG/FRAG2 and TP correctly, headers: FRAG: [id=999, frag_id=1, num_frags=3], UDP: [cluster_name=MainCluster]
> Recommendation: Let bundling size limit be just that -- the maximum size that bundles will be built to. If a maximum UDP packet size restriction is desired then add that as a separate option. However I don't recommend this because this error is pretty much fatal if the wrong kind of message is exceeding the limit. Once the packet has made it past the frag protocols it is going to be the size it wants to be. Refusing to put it on the network only has bad outcomes because there is no recovery.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-861) Wrong installation date in product info report
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-861?page=com.atlassian.jira.plugin... ]
Marek Kopecký moved JBEAP-572 to WFCORE-861:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-861 (was: JBEAP-572)
Workflow: GIT Pull Request workflow (was: CDW v1)
Affects Version/s: 2.0.0.Alpha11
(was: EAP 7.0.0.DR7)
Component/s: CLI
(was: CLI)
Target Release: (was: EAP 7.0.0.GA)
> Wrong installation date in product info report
> ----------------------------------------------
>
> Key: WFCORE-861
> URL: https://issues.jboss.org/browse/WFCORE-861
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Alpha11
> Reporter: Marek Kopecký
> Assignee: ehsavoie Hugonnet
>
> *Description of problem:*
> Product info report shows wrong installation date in EAP from zip installation. Reported installation date is date of EAP building.
> *How reproducible:*
> Always on EAP from zip installation
> *Steps to Reproduce:*
> # get fresh EAP from zip
> # ./standalone.sh
> # ./jboss-cli.sh -c
> # :product-info
> *Actual results:*
> installation-date is a date of EAP building
> *Expected results:*
> If Product Install Date is not available in zip installation, EAP do not report it.
> *Additional info:*
> Installation date is reported correctly, when installer is used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-860) Use notifications to help the scanner get a proper status of all deployments between scans
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-860:
----------------------------------------
Summary: Use notifications to help the scanner get a proper status of all deployments between scans
Key: WFCORE-860
URL: https://issues.jboss.org/browse/WFCORE-860
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Affects Versions: 2.0.0.Alpha12
Reporter: ehsavoie Hugonnet
Assignee: ehsavoie Hugonnet
As written in https://issues.jboss.org/browse/WFLY-3198?focusedCommentId=12958470&page=...
We should look into using the management API notification stuff Jeff Mesnil has done/is doing. The scanner subsystem can register listeners and the deployment ops can emit events. This can be used to keep the scanner aware of changes to the deployments part of the management model independent of the periodic scans.
This would close a gap that exists where the scan could be configured to run infrequently (say 10 mins), the .undeployed app gets deployed via console, and then before the scanner runs again and cleans out the .undeployed, the server is reloaded/restarted.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFCORE-859) Product info report show wrong "host-cpu-arch" on amd64 architecture with 32-bit version of java
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-859?page=com.atlassian.jira.plugin... ]
Marek Kopecký moved JBEAP-570 to WFCORE-859:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-859 (was: JBEAP-570)
Workflow: GIT Pull Request workflow (was: CDW v1)
Affects Version/s: 2.0.0.Alpha11
(was: EAP 7.0.0.DR7)
Component/s: CLI
(was: CLI)
Target Release: (was: EAP 7.0.0.GA)
> Product info report show wrong "host-cpu-arch" on amd64 architecture with 32-bit version of java
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-859
> URL: https://issues.jboss.org/browse/WFCORE-859
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Alpha11
> Reporter: Marek Kopecký
> Assignee: ehsavoie Hugonnet
>
> *Description of problem:*
> Product info report show wrong "host-cpu-arch" on amd64 architecture with 32-bit version of java (example: "Linux 32-bit x86" version of IBM JDK 8). Host-cpu-arch is probably generated by JDK version.
> *Steps to Reproduce:*
> # use 32bit java on 64bit architecture of CPU
> # get fresh EAP from zip
> # ./standalone.sh
> # ./jboss-cli.sh -c
> # :product-info
> *Actual results:*
> {noformat}
> ...
> "host-cpu" => {
> "host-cpu-arch" => "x86",
> "host-core-count" => 8
> },
> ...
> {noformat}
> *Expected results:*
> Correct value for "host-cpu-arch":
> {noformat}
> ...
> "host-cpu" => {
> "host-cpu-arch" => "amd64",
> "host-core-count" => 8
> },
> ...
> {noformat}
> *Additional info:*
> Architecture from product report is architecture of java (not architecture of CPU). There should be at least something like "host-cpu-arch (generated by JVM)" in product report.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-5047) Many opened JMS sessions cause connection timed out
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFLY-5047?page=com.atlassian.jira.plugin.... ]
Erich Duda moved JBEAP-568 to WFLY-5047:
----------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5047 (was: JBEAP-568)
Workflow: GIT Pull Request workflow (was: CDW v1)
Affects Version/s: 10.0.0.Alpha6
(was: EAP 7.0.0.DR6)
Component/s: JMS
(was: JMS)
Target Release: (was: EAP 7.0.0.GA)
> Many opened JMS sessions cause connection timed out
> ---------------------------------------------------
>
> Key: WFLY-5047
> URL: https://issues.jboss.org/browse/WFLY-5047
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Alpha6
> Environment: Fedora 22
> Open JDK 8
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Attachments: 30MDB60maxSession.log
>
>
> When 30 MDB consumers are deployed with property maxSession set on 60, the server stops to accept connections and the connection timed out exception is thrown. However when 60 MDB consumers are deployed with property maxSession set on 30, the server accepts connection as expected, only "Failed to open a socket" exception is occurred, because maximum of opened sockets is reached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-5046) Clients should not throw HornetQException/JMSException to application code during failover
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-5046?page=com.atlassian.jira.plugin.... ]
Miroslav Novak moved JBEAP-567 to WFLY-5046:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5046 (was: JBEAP-567)
Workflow: GIT Pull Request workflow (was: CDW v1)
Affects Version/s: 10.0.0.Alpha1
(was: EAP 7.0.0.DR1)
Component/s: JMS
(was: JMS)
Target Release: (was: EAP 7.0.0.GA)
> Clients should not throw HornetQException/JMSException to application code during failover
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-5046
> URL: https://issues.jboss.org/browse/WFLY-5046
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 10.0.0.Alpha1
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Priority: Critical
>
> Currently standalone JMS client throws exception (HornetQException or JMSException) to client application code during failover/failback and leaves on application programmer to handle this exception and retry the last operation.
> This makes client code complex and developer must spent additional effort to handle those edge cases. This is complicated to achieve especially for consumer with transacted session of client acknowledge.
> Goal of this RFE is to provide exception free behaviour for standalone JMS clients.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months
[JBoss JIRA] (WFLY-5045) Undertow mod_cluster CLI: IllegalArgumentException: value is null on modcluster:read-resource
by Michal Karm Babacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5045?page=com.atlassian.jira.plugin.... ]
Michal Karm Babacek moved JBEAP-563 to WFLY-5045:
-------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5045 (was: JBEAP-563)
Workflow: GIT Pull Request workflow (was: CDW v1)
Affects Version/s: 10.0.0.Alpha6
(was: EAP 7.0.0.DR7)
Component/s: Web (Undertow)
(was: Web (Undertow))
Target Release: (was: EAP 7.0.0.GA)
> Undertow mod_cluster CLI: IllegalArgumentException: value is null on modcluster:read-resource
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-5045
> URL: https://issues.jboss.org/browse/WFLY-5045
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Alpha6
> Environment: EAP 7.0.0.DR7, Undertow 1.3.0.Beta4
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Priority: Blocker
>
> *Undertow 1.3.0.Beta3*, *EAP 7.0.0.DR6* worked perfectly with {{modcluster:read-resource}} recursive operations:
> h3. Setup
> # Add socker binding: {{/socket-binding-group=standard-sockets/socket-binding=mod-cluster-adv:add(multicast-address=224.0.1.105,port=65530)}}
> # Configure mod_cluster proxy: {{/subsystem=undertow/configuration=filter/mod-cluster=modcluster:add(advertise-frequency=10000,advertise-path=/,advertise-protocol=http,advertise-socket-binding=mod-cluster-adv,management-socket-binding=http,management-access-predicate=undefined,broken-node-timeout=10,cached-connections-per-thread=5,connection-idle-timeout=60,connections-per-thread=10,health-check-interval=10000,max-request-time=-1,request-queue-size=10,security-key=undefined,security-realm=undefined,worker=default)}}
> # Add mod_cluster filter: {{/subsystem=undertow/server=default-server/host=default-host/filter-ref=modcluster:add()}}
> # As soon as worker connects: {noformat}UT005053: Registering node localhost, connection: ajp://karm.brq.redhat.com:8019/?#
> UT005045: Registering context /clusterbench, for node localhost{noformat}, we try to list the configuration:
> # List configuration including runtime recursively: {{/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}
> h3. Error
> The output of the last aforementioned command with *EAP 7.0.0.DR6, Undertow 1.3.0.Beta3* is:{noformat}
> {
> "outcome" => "success",
> "result" => {
> "advertise-frequency" => 10000,
> "advertise-path" => "/",
> "advertise-protocol" => "http",
> "advertise-socket-binding" => "mod-cluster-adv",
> "broken-node-timeout" => 10,
> "cached-connections-per-thread" => 5,
> "connection-idle-timeout" => 60,
> "connections-per-thread" => 10,
> "health-check-interval" => 10000,
> "management-access-predicate" => undefined,
> "management-socket-binding" => "http",
> "max-request-time" => -1,
> "request-queue-size" => 10,
> "security-key" => undefined,
> "security-realm" => undefined,
> "worker" => "default",
> "balancer" => {"mycluster" => {"node" => {"localhost" => {
> "load" => 81,
> "status" => "NODE_UP",
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "enabled"
> }}
> }}}}
> }
> }{noformat} whereas with *EAP 7.0.0.DR7, Undertow 1.3.0.Beta4*; it is: {noformat}ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("subsystem" => "undertow"),
> ("configuration" => "filter"),
> ("mod-cluster" => "modcluster"),
> ("balancer" => "mycluster")
> ]): java.lang.IllegalArgumentException: value is null
> at org.jboss.dmr.ModelNode.<init>(ModelNode.java:162)
> at org.wildfly.extension.undertow.filters.ModClusterBalancerDefinition$3.handleNode(ModClusterBalancerDefinition.java:117)
> at org.wildfly.extension.undertow.filters.ModClusterBalancerDefinition$AbstractBalancerOperation.execute(ModClusterBalancerDefinition.java:173)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:248)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:701)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:841)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:632)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:357)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1235)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:223)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:207)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:129)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:151)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:147)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:147)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320){noformat}It is noteworthy that *until* any worker joins the balancer, the operation works just fine (DR7, Beta4): {noformat}{
> "outcome" => "success",
> "result" => {
> "advertise-frequency" => 10000,
> "advertise-path" => "/",
> "advertise-protocol" => "http",
> "advertise-socket-binding" => "mod-cluster-adv",
> "broken-node-timeout" => 10,
> "cached-connections-per-thread" => 5,
> "connection-idle-timeout" => 60,
> "connections-per-thread" => 10,
> "health-check-interval" => 10000,
> "management-access-predicate" => undefined,
> "management-socket-binding" => "http",
> "max-request-time" => -1,
> "request-queue-size" => 10,
> "security-key" => undefined,
> "security-realm" => undefined,
> "use-alias" => true,
> "worker" => "default",
> "balancer" => undefined
> }
> }{noformat}
> I see this issue as a {color:red}Blocker{color}, because it not only breaks all current test automation but also renders the Undertow mod_cluster proxy CLI hardly usable for any administration.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 8 months