[JBoss JIRA] (WFLY-11394) Wrong units of jvm.uptime metric - milliseconds vs. seconds
by Rostislav Svoboda (Jira)
[ https://issues.jboss.org/browse/WFLY-11394?page=com.atlassian.jira.plugin... ]
Rostislav Svoboda commented on WFLY-11394:
------------------------------------------
When I ask for JSON I get milliseconds, this is weird.
{code}
curl http://localhost:9990/metrics/base/jvm.uptime -H "Accept: application/json" && echo " vs." && curl http://localhost:9990/metrics/base/jvm.uptime
{ "jvm.uptime" : 2504965}
vs.
# HELP base:jvm_uptime_seconds Displays the start time of the Java virtual machine in milliseconds. This attribute displays the approximate time when the Java virtual machine started.
# TYPE base:jvm_uptime_seconds gauge
base:jvm_uptime_seconds 2504.986
{code}
> Wrong units of jvm.uptime metric - milliseconds vs. seconds
> -----------------------------------------------------------
>
> Key: WFLY-11394
> URL: https://issues.jboss.org/browse/WFLY-11394
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Reporter: Rostislav Svoboda
> Assignee: Jeff Mesnil
> Priority: Major
>
> Wrong units of jvm.uptime metric - milliseconds vs. seconds
> {code}
> curl -H "Accept: application/json" -X OPTIONS http://localhost:9990/metrics/base/jvm.uptime
> {
> "jvm.uptime": {
> "unit": "milliseconds",
> "type": "gauge",
> "description": "Displays the start time of the Java virtual machine in milliseconds. This attribute displays the approximate time when the Java virtual machine started.",
> "displayName": "JVM Uptime",
> "tags": ""
> }
> {code}
> This metric reports results in seconds, not in milliseconds as description says.
> {code}
> curl http://localhost:9990/metrics/base/jvm.uptime
> # HELP base:jvm_uptime_seconds Displays the start time of the Java virtual machine in milliseconds. This attribute displays the approximate time when the Java virtual machine started.
> # TYPE base:jvm_uptime_seconds gauge
> base:jvm_uptime_seconds 2011.875
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11394) Wrong units of jvm.uptime metric - milliseconds vs. seconds
by Rostislav Svoboda (Jira)
Rostislav Svoboda created WFLY-11394:
----------------------------------------
Summary: Wrong units of jvm.uptime metric - milliseconds vs. seconds
Key: WFLY-11394
URL: https://issues.jboss.org/browse/WFLY-11394
Project: WildFly
Issue Type: Bug
Components: MP Metrics
Reporter: Rostislav Svoboda
Assignee: Jeff Mesnil
Wrong units of jvm.uptime metric - milliseconds vs. seconds
{code}
curl -H "Accept: application/json" -X OPTIONS http://localhost:9990/metrics/base/jvm.uptime
{
"jvm.uptime": {
"unit": "milliseconds",
"type": "gauge",
"description": "Displays the start time of the Java virtual machine in milliseconds. This attribute displays the approximate time when the Java virtual machine started.",
"displayName": "JVM Uptime",
"tags": ""
}
{code}
This metric reports results in seconds, not in milliseconds as description says.
{code}
curl http://localhost:9990/metrics/base/jvm.uptime
# HELP base:jvm_uptime_seconds Displays the start time of the Java virtual machine in milliseconds. This attribute displays the approximate time when the Java virtual machine started.
# TYPE base:jvm_uptime_seconds gauge
base:jvm_uptime_seconds 2011.875
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-11393) Wrong description of jvm.uptime metric
by Rostislav Svoboda (Jira)
Rostislav Svoboda created WFLY-11393:
----------------------------------------
Summary: Wrong description of jvm.uptime metric
Key: WFLY-11393
URL: https://issues.jboss.org/browse/WFLY-11393
Project: WildFly
Issue Type: Bug
Components: MP Metrics
Reporter: Rostislav Svoboda
Assignee: Jeff Mesnil
Wrong description of jvm.uptime metric
{code}
curl -H "Accept: application/json" -X OPTIONS http://localhost:9990/metrics/base/jvm.uptime
{
"jvm.uptime": {
"unit": "milliseconds",
"type": "gauge",
"description": "Displays the start time of the Java virtual machine in milliseconds. This attribute displays the approximate time when the Java virtual machine started.",
"displayName": "JVM Uptime",
"tags": ""
}
{code}
This metric doesn't display start time, but uptime of JVM. Description for the metric should be fixed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (DROOLS-3027) [DMN Designer] Differentiate zero and non zero custom data types
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3027?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3027:
--------------------------------
Description:
There is no visual information if no custom data type is defined. In the attached dialog we should differentiate between states when no custom da taype is declared and when some custom data types are declared. The same way we do it in list of spaces and list of projects.
h2. Manual acceptance test
- Create new model, empty state indicated, save and reopen
- Create some data type, not empty state indicated, save and reopen
- Remove the data type, empty state indicated, save and reopen
- Firefox, Edge, Chrome
was:There is no visual information if no custom data type is defined. In the attached dialog we should differentiate between states when no custom da taype is declared and when some custom data types are declared. The same way we do it in list of spaces and list of projects.
> [DMN Designer] Differentiate zero and non zero custom data types
> ----------------------------------------------------------------
>
> Key: DROOLS-3027
> URL: https://issues.jboss.org/browse/DROOLS-3027
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: UX, drools-tools
> Attachments: Screenshot from 2018-09-24 18-12-02.png
>
>
> There is no visual information if no custom data type is defined. In the attached dialog we should differentiate between states when no custom da taype is declared and when some custom data types are declared. The same way we do it in list of spaces and list of projects.
> h2. Manual acceptance test
> - Create new model, empty state indicated, save and reopen
> - Create some data type, not empty state indicated, save and reopen
> - Remove the data type, empty state indicated, save and reopen
> - Firefox, Edge, Chrome
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-10795) Non-Elytron SSL configuration won't establish secure channel between worker and balancer
by Jan Kašík (Jira)
[ https://issues.jboss.org/browse/WFLY-10795?page=com.atlassian.jira.plugin... ]
Jan Kašík closed WFLY-10795.
----------------------------
Thanks! Fixed -- all work is done. Closing.
> Non-Elytron SSL configuration won't establish secure channel between worker and balancer
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-10795
> URL: https://issues.jboss.org/browse/WFLY-10795
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: No Release
> Environment: Latest snapshot from ci.wildfly.org
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 14.0.0.Beta2
>
> Attachments: confs.zip
>
>
> When running scenario, where connection between worker and balancer is secured with SSL, worker fails to register on balancer.
> Worker obviously tries to send INFO commands, though it sends it as a 'plain text' to a secured channel.
> I enabled SSL debugging, and such unsecured-secured communication causes this error:
> {code}
> 09:42:20,456 INFO [stdout] (default I/O-4) Using SSLEngineImpl.
> 09:42:20,458 INFO [stdout] (default I/O-4) Allow unsafe renegotiation: false
> 09:42:20,458 INFO [stdout] (default I/O-4) Allow legacy hello messages: true
> 09:42:20,458 INFO [stdout] (default I/O-4) Is initial handshake: true
> 09:42:20,459 INFO [stdout] (default I/O-4) Is secure renegotiation: false
> 09:42:20,459 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
> 09:42:20,460 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
> 09:42:20,461 INFO [stdout] (default I/O-4) Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
> 09:42:20,479 INFO [stdout] (default I/O-4) default I/O-4, fatal error: 80: problem unwrapping net record
> 09:42:20,480 INFO [stdout] (default I/O-4) javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, SEND TLSv1.2 ALERT: fatal, description = internal_error
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, WRITE: TLSv1.2 Alert, length = 2
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, called closeInbound()
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, called closeOutbound()
> 09:42:20,480 INFO [stdout] (default I/O-4) default I/O-4, closeOutboundInternal()
> {code}
> What bothers me, that there are no other errors (bad certificate, CLI error...) in log regarding this. Apart from:
> {code}
> 09:45:42,653 WARN [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p14-t16) ISPN000197: Error updating cluster member list: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 6 from wildfly-14.0.0.Beta2-SNAPSHOT-2
> at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Suppressed: org.infinispan.util.logging.TraceException
> at org.infinispan.remoting.transport.Transport.invokeRemotely(Transport.java:75)
> at org.infinispan.topology.ClusterTopologyManagerImpl.confirmMembersAvailable(ClusterTopologyManagerImpl.java:525)
> at org.infinispan.topology.ClusterTopologyManagerImpl.updateCacheMembers(ClusterTopologyManagerImpl.java:508)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleClusterView(ClusterTopologyManagerImpl.java:321)
> at org.infinispan.topology.ClusterTopologyManagerImpl.access$500(ClusterTopologyManagerImpl.java:87)
> at org.infinispan.topology.ClusterTopologyManagerImpl$ClusterViewListener.lambda$handleViewChange$0(ClusterTopologyManagerImpl.java:731)
> at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:175)
> at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:37)
> at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:227)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> {code}
> Configuration using non-Elytron configuration was possible before, hence this is a regression.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-10834) Load provider settings is not taken into account in mod_cluster subsystem
by Jan Kašík (Jira)
[ https://issues.jboss.org/browse/WFLY-10834?page=com.atlassian.jira.plugin... ]
Jan Kašík closed WFLY-10834.
----------------------------
Fixed! No more work left to be done.
> Load provider settings is not taken into account in mod_cluster subsystem
> -------------------------------------------------------------------------
>
> Key: WFLY-10834
> URL: https://issues.jboss.org/browse/WFLY-10834
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: No Release
> Environment: Latest nightly from ci.wildfly.org
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 14.0.0.Beta2
>
>
> Everything works in version with old subsytem with this settings (load is properly reported to balancer):
> {code:xml}
> <subsystem
> xmlns="urn:jboss:domain:modcluster:3.0">
> <mod-cluster-config advertise-socket="modcluster" auto-enable-contexts="true" connector="ajp">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> Same configuration for latest snapshot doesn't work (load remains at 1):
> {code:xml}
> <subsystem
> xmlns="urn:jboss:domain:modcluster:4.0">
> <proxy name="default" advertise-socket="modcluster" auto-enable-contexts="true" connector="ajp">
> <dynamic-load-provider>
> <load-metric type="cpu" weight="1"/>
> </dynamic-load-provider>
> </proxy>
> </subsystem>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (WFLY-10745) Update the multi-JSF installer to be able to install Mojarra and MyFaces 2.3.x versions in addition to 2.1.x and 2.2.x versions
by Jan Kašík (Jira)
[ https://issues.jboss.org/browse/WFLY-10745?page=com.atlassian.jira.plugin... ]
Jan Kašík closed WFLY-10745.
----------------------------
There is no more left work to be done.
> Update the multi-JSF installer to be able to install Mojarra and MyFaces 2.3.x versions in addition to 2.1.x and 2.2.x versions
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10745
> URL: https://issues.jboss.org/browse/WFLY-10745
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Kašík
> Assignee: Dmitrii Tikhomirov
> Priority: Major
> Fix For: 14.0.0.Final
>
> Attachments: hello_jsf.war
>
>
> It is currently not possible to deploy *.cli built by multi-jsf-installer shipped with WildFly. When attempting to deploy, this message will appear:
> {code}
> org.jboss.as.cli.CommandFormatException: org.jboss.as.cli.CommandLineException: java.util.concurrent.ExecutionException: org.jboss.as.cli.CommandLineException: Failed to locate /tmp/vfs/cli-1528866094723/cli-1528866094723450313ef1dc90cff/install-mojarra-2.2.17.cli-212b6d42ba0c47e1/jsf-api-2.2.17.jar, if you defined a nonexistent resource on purpose you should use the --allow-nonexistent-resources option
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months
[JBoss JIRA] (JGRP-2314) DNS_PING: port_range is ignored
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2314?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2314:
--------------------------------
The attr port_range is now taken into account. Also, the port returned from DNS is ignored, as it is never the correct JGroups port anyway (DNS/Kubernetes/Openshift doesn't know it).
> DNS_PING: port_range is ignored
> -------------------------------
>
> Key: JGRP-2314
> URL: https://issues.jboss.org/browse/JGRP-2314
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16
>
>
> When sending GET_MBRS_REQ messages to addresses fetched from Kubernetes, only the bind_port is used, rather than range {{bind_port .. bind_port+port_range}}.
> We can simply copy the code from {{KUBE_PING}} to do this.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 8 months