[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)
10 years, 11 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)
10 years, 11 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)
10 years, 11 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)
10 years, 11 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)
10 years, 11 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)
10 years, 11 months
[JBoss JIRA] (WFCORE-858) CLI ends with NullPointerException after "ls" command and "tab" key
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-858?page=com.atlassian.jira.plugin... ]
Marek Kopecký moved JBEAP-561 to WFCORE-858:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-858 (was: JBEAP-561)
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)
> CLI ends with NullPointerException after "ls" command and "tab" key
> -------------------------------------------------------------------
>
> Key: WFCORE-858
> URL: https://issues.jboss.org/browse/WFCORE-858
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Alpha11
> Reporter: Marek Kopecký
> Assignee: Alexey Loubyansky
>
> *Description of problem:*
> CLI ends with java.lang.NullPointerException after "ls" command and "tab" key
> *How reproducible:*
> 100 %
> *Steps to Reproduce:*
> # ./standalone.sh
> # ./jboss-cli.sh -c
> # ls / -l
> #* don't press "enter" key
> # press "tab" key
> *Actual results:*
> {noformat}
> java.lang.NullPointerException
> at org.jboss.as.cli.handlers.LsHandler.getOperationRequestAddress(LsHandler.java:402)
> at org.jboss.as.cli.handlers.LsHandler.access$000(LsHandler.java:52)
> at org.jboss.as.cli.handlers.LsHandler$1.canAppearNext(LsHandler.java:75)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:257)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:73)
> at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:126)
> at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63)
> at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:122)
> at org.jboss.aesh.console.Console.complete(Console.java:1227)
> at org.jboss.aesh.console.Console.parseOperation(Console.java:551)
> at org.jboss.aesh.console.Console.read(Console.java:453)
> at org.jboss.aesh.console.Console.read(Console.java:347)
> at org.jboss.as.cli.impl.Console$Factory$1.readLine(Console.java:198)
> at org.jboss.as.cli.impl.CommandContextImpl.interact(CommandContextImpl.java:1322)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:272)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.jboss.modules.Module.run(Module.java:308)
> at org.jboss.modules.Main.main(Main.java:487)
> {noformat}
> *Expected results:*
> No errors on output
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-4801) When expression is used in jndi name attribute of datasource then test-connection-in-pool operation is not working
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4801?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4801:
-----------------------------------------------
hsvabek(a)redhat.com changed the Status of [bug 1232781|https://bugzilla.redhat.com/show_bug.cgi?id=1232781] from ON_QA to VERIFIED
> When expression is used in jndi name attribute of datasource then test-connection-in-pool operation is not working
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4801
> URL: https://issues.jboss.org/browse/WFLY-4801
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.Alpha3
> Reporter: Chao Wang
> Assignee: Chao Wang
> Fix For: 9.0.0.Final, 10.0.0.Alpha4
>
>
> {noformat}
> Description of problem:
> ========================
> - Expression is added in the datasource JNDI name attribute as below:
> -----
> <datasource jndi-name="${ds}" pool-name="ExampleDS" enabled="true" use-java-context="true">
> -----
> - Value for the expression is passed to the JBoss server during the JBoss startup as below:
> -----
> ./standalone.sh -Dds=java:jboss/datasources/ExampleDS
> -----
> - In the server.log file below is the information regarding the datasource.
> -----
> INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [${ds}]
> -----
> - Test the datasource using the below command and here is the result:
> ----
> [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:test-connection-in-pool()
> {
> "outcome" => "failed",
> "failure-description" => "JBAS010440: failed to invoke operation: JBAS010442: failed to match pool. Check JndiName: java:/${ds}",
> "rolled-back" => true
> }
> ----
> - Here is the information regarding the JNDI name attribute:
> ----
> [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:read-resource-description(recursive=true)
> {
> "outcome" => "success",
> "result" => {
> :
> "jndi-name" => {
> "type" => STRING,
> "description" => "Specifies the JNDI name for the datasource",
> "expressions-allowed" => true,
> "nillable" => false,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> :
> }
> -----
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (JASSIST-245) Javassist 3.19.0-GA causes compilation warnings with -Xlint:classfile
by wuwen wuwen (JIRA)
[ https://issues.jboss.org/browse/JASSIST-245?page=com.atlassian.jira.plugi... ]
wuwen wuwen edited comment on JASSIST-245 at 8/2/15 10:09 PM:
--------------------------------------------------------------
{code}<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<testSource>1.8</testSource>
<testTarget>1.8</testTarget>
<compilerArgument>-parameters</compilerArgument>
</configuration>
</plugin>{code}
maybe that's the reason ?
was (Author: wuwen5):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<testSource>1.8</testSource>
<testTarget>1.8</testTarget>
<compilerArgument>-parameters</compilerArgument>
</configuration>
</plugin>
maybe that's the reason ?
> Javassist 3.19.0-GA causes compilation warnings with -Xlint:classfile
> ---------------------------------------------------------------------
>
> Key: JASSIST-245
> URL: https://issues.jboss.org/browse/JASSIST-245
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.19.0-GA
> Reporter: David Carr
> Assignee: Shigeru Chiba
>
> Tested using Oracle Java 1.8.0_40.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months