[JBoss JIRA] (WFLY-11458) Timed - difference between Prometheus and JSON format
by Jan Martiska (Jira)
[ https://issues.jboss.org/browse/WFLY-11458?page=com.atlassian.jira.plugin... ]
Jan Martiska edited comment on WFLY-11458 at 12/14/18 5:58 AM:
---------------------------------------------------------------
I guess the problem is here https://github.com/smallrye/smallrye-metrics/blob/1.1.2/implementation/sr... - IIUC {{scaleToBase}} is for converting to seconds (which is the unit in which we should always be presenting snapshot summaries), but as the input unit param, it is being given {{md.getUnit()}} which denotes the base unit of the metric, but it should instead be NANOSECONDS because that's the unit in which the data is internally stored. So in our case it converts to seconds, but converts from the wrong input unit.
I suppose the {{scaleToBase}} method be rather named {{convertToSecondsOrBytes}} which is what it really does.
Current proposal for fix, but will need some more testing (and adding some more comments because the code is very hard to read IMO): https://github.com/jmartisk/smallrye-metrics/commits/issue-40
Surprisingly this does not seem to be covered in the TCKs either, I will consider adding some tests for that
was (Author: jmartisk):
I guess the problem is here https://github.com/smallrye/smallrye-metrics/blob/1.1.2/implementation/sr... - IIUC {{scaleToBase}} is for converting to seconds (which is the unit in which we should always be presenting snapshot summaries), but as the input unit param, it is being given {{md.getUnit()}} which denotes the base unit of the metric, but it should instead be NANOSECONDS because that's the unit in which the data is internally stored. So in our case it converts to seconds, but converts from the wrong input unit.
I suppose the {{scaleToBase}} method be rather named {{convertToSecondsOrBytes}} which is what it really does.
Current proposal for fix, but will need some more testing (and adding some more comments because the code is very hard to read IMO): https://github.com/jmartisk/smallrye-metrics/commits/issue-40
> Timed - difference between Prometheus and JSON format
> -----------------------------------------------------
>
> Key: WFLY-11458
> URL: https://issues.jboss.org/browse/WFLY-11458
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Affects Versions: 15.0.0.Final
> Reporter: Rostislav Svoboda
> Assignee: Bartosz Baranowski
> Priority: Critical
>
> There are differences in reported results between Prometheus and JSON format.
> When using the same deployment with OpenLiberty there are no differences in reported results between Prometheus and JSON format.
> https://github.com/smallrye/smallrye-metrics/issues/40
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFCORE-1427) Provide ability to suspend and resume the set of servers managed by a specific host controller
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFCORE-1427?page=com.atlassian.jira.plugi... ]
Yeray Borges updated WFCORE-1427:
---------------------------------
Summary: Provide ability to suspend and resume the set of servers managed by a specific host controller (was: Add a timeout param to reload op and use it for "graceful reload")
> Provide ability to suspend and resume the set of servers managed by a specific host controller
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1427
> URL: https://issues.jboss.org/browse/WFCORE-1427
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Management
> Reporter: Brian Stansberry
> Assignee: Yeray Borges
> Priority: Major
>
> So instead of
> {code}
> :suspend(20)
> :reload
> {code}
> It's just
> {code}
> :reload(20)
> {code}
> The high level 'reload' command in the CLI should take a --timeout param as well.
> If doing the graceful suspend as part of server side ":reload" handling proves problematic (I haven't looked into it at all before filing this) then a simpler alternative is to only go with the --timeout param on the CLI reload command, and have the CLI implement the graceful behavior internally by first calling :suspend and then :reload. Web console could do the same thing.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3430) [DMN Designer] [Edge] Update Name via Name And DataType dialog
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3430?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-3430:
----------------------------------------
Sorry [~dadossan] an Edge issue :-(
I'd suggest putting a break point in {{NameAndDataTypePopoverViewImpl.onNameChange(..)}} and seeing what happens on Edge.
> [DMN Designer] [Edge] Update Name via Name And DataType dialog
> --------------------------------------------------------------
>
> Key: DROOLS-3430
> URL: https://issues.jboss.org/browse/DROOLS-3430
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.16.0.Final
> Environment: Win10, Edge, eap-7.2
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools, edge
> Attachments: Screenshot from 2018-12-13 07-50-37.png
>
>
> User can rename boxed expression elements by single click into given grid cell. Then the *Name and DataType dialog* is shown to the user where he can rename the given element. The problem on *Edge* is confirming this renaming. On other browsers renaming is confirmed with clicking somewhere into canvas. On the *Edge* clicking to canvas close the dialog and renaming is discarded.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3430) [DMN Designer] [Edge] Update Name via Name And DataType dialog
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3430?page=com.atlassian.jira.plugi... ]
Michael Anstis reassigned DROOLS-3430:
--------------------------------------
Assignee: Daniel José dos Santos (was: Michael Anstis)
> [DMN Designer] [Edge] Update Name via Name And DataType dialog
> --------------------------------------------------------------
>
> Key: DROOLS-3430
> URL: https://issues.jboss.org/browse/DROOLS-3430
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.16.0.Final
> Environment: Win10, Edge, eap-7.2
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools, edge
> Attachments: Screenshot from 2018-12-13 07-50-37.png
>
>
> User can rename boxed expression elements by single click into given grid cell. Then the *Name and DataType dialog* is shown to the user where he can rename the given element. The problem on *Edge* is confirming this renaming. On other browsers renaming is confirmed with clicking somewhere into canvas. On the *Edge* clicking to canvas close the dialog and renaming is discarded.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3412) Performance degradation with session pools
by Tibor Zimányi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3412?page=com.atlassian.jira.plugi... ]
Tibor Zimányi edited comment on DROOLS-3412 at 12/14/18 5:24 AM:
-----------------------------------------------------------------
[~christianl] Hi, the PR got merged. You can retest when the SNAPSHOTs get rebuilt.
was (Author: tzimanyi):
[~christianl] Hi, the PR got merged. You can retest.
> Performance degradation with session pools
> ------------------------------------------
>
> Key: DROOLS-3412
> URL: https://issues.jboss.org/browse/DROOLS-3412
> Project: Drools
> Issue Type: Bug
> Reporter: Christian Liebhardt
> Assignee: Mario Fusco
> Priority: Major
> Attachments: gc.png
>
>
> Hello,
> We've today updates to Drools 7.15 and as discussed with DROOLS-3228 we changed our code from calling _StatefulKnowledgeSessionImpl.reset_ ourselves to _KieSessionsPool_. However we then recognized that our application quickly became slower and slower over time (roughly after a few minutes of uptime, or a couple of hundred session create/dispose cycles).
> I haven't yet found the reason what is causing the slow down. However I think there is a difference in how we reset our sessions before session pools and how session pools do it. Perhaps that is a lead.
> *What we did*
> # Create a session
> # Use the session
> # Dispose and reset the session and go back to 2 for the next facts
> *What happens with session pools*
> # Create a session
> # Use the session
> # Skip dispose (because of _pool != null_ in the dispose method), reset the session and go back to 2 for the next facts
> So the difference seems to be that with session pools the session doesn't get disposed before reset it called. If I do the same without session pools then I also see the same slow down. So it seems that something is left behind and causes a slow down. The results however seem to be correct, so the right consequences appear to be triggered.
> An example on how we use the session pool can be found here: https://github.com/liebharc/JavaRules/blob/master/src/main/java/com/githu...
> Thanks once more for your help.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3412) Performance degradation with session pools
by Tibor Zimányi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3412?page=com.atlassian.jira.plugi... ]
Tibor Zimányi commented on DROOLS-3412:
---------------------------------------
[~christianl] Hi, the PR got merged. You can retest.
> Performance degradation with session pools
> ------------------------------------------
>
> Key: DROOLS-3412
> URL: https://issues.jboss.org/browse/DROOLS-3412
> Project: Drools
> Issue Type: Bug
> Reporter: Christian Liebhardt
> Assignee: Mario Fusco
> Priority: Major
> Attachments: gc.png
>
>
> Hello,
> We've today updates to Drools 7.15 and as discussed with DROOLS-3228 we changed our code from calling _StatefulKnowledgeSessionImpl.reset_ ourselves to _KieSessionsPool_. However we then recognized that our application quickly became slower and slower over time (roughly after a few minutes of uptime, or a couple of hundred session create/dispose cycles).
> I haven't yet found the reason what is causing the slow down. However I think there is a difference in how we reset our sessions before session pools and how session pools do it. Perhaps that is a lead.
> *What we did*
> # Create a session
> # Use the session
> # Dispose and reset the session and go back to 2 for the next facts
> *What happens with session pools*
> # Create a session
> # Use the session
> # Skip dispose (because of _pool != null_ in the dispose method), reset the session and go back to 2 for the next facts
> So the difference seems to be that with session pools the session doesn't get disposed before reset it called. If I do the same without session pools then I also see the same slow down. So it seems that something is left behind and causes a slow down. The results however seem to be correct, so the right consequences appear to be triggered.
> An example on how we use the session pool can be found here: https://github.com/liebharc/JavaRules/blob/master/src/main/java/com/githu...
> Thanks once more for your help.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11517) Exception while running reports java.lang.StringIndexOutOfBoundsException: String index out of range: 10
by Bartosz Baranowski (Jira)
[ https://issues.jboss.org/browse/WFLY-11517?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski commented on WFLY-11517:
-------------------------------------------
[~suganya_rajeswaran] - can we get reproducer?
> Exception while running reports java.lang.StringIndexOutOfBoundsException: String index out of range: 10
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11517
> URL: https://issues.jboss.org/browse/WFLY-11517
> Project: WildFly
> Issue Type: Bug
> Reporter: Suganya Rajeswaran
> Assignee: Jason Greene
> Priority: Major
>
> Hi,
>
> I tried running a report in my application which is running on WildFly 14 server. I am getting the following exception,
>
> java.lang.StringIndexOutOfBoundsException: String index out of range: 10
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at in.textech.common.SessionFilter.doFilter(SessionFilter.java:86)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 10
> at java.lang.String.substring(String.java:1963)
> at in.textech.library.FormatModifier.dbFormat(FormatModifier.java:79)
> at org.apache.jsp.reportViewers.EmployeePermission_002dviewer_jsp._jspService(EmployeePermission_002dviewer_jsp.java:204)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> ... 50 more
>
> But the same works on JBoss AS 7. Kindly help me out to rectify this.
> Is there anything that I am missing out?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months