Bug 1018792

Summary:	Value overflow when entering large numeric value to form
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Martin Svehla <msvehla>
Component:	Web Console	Assignee:	Harald Pehl <hpehl>
Status:	CLOSED EOL	QA Contact:	Pavel Jelinek <pjelinek>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.2.0	CC:	hbraun, hpehl, jkudrnac, msvehla, pjelinek
Target Milestone:	DR0
Target Release:	EAP 6.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-08-19 12:47:48 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Martin Svehla 2013-10-14 12:20:52 UTC

Description of problem:
When entering large value to numeric field, it overflows to -1 (and then the form is showing 0).


Version-Release number of selected component (if applicable):
EAP 6.2.0.ER5


How reproducible:
Go for example to Profile -> Messaging -> Clustering -> Discovery. Go to edit mode and add 1111111111111111111 to Initial Wait Timeout field. Upon save, the value shown in console is 0, if I enter the edit mode again, there's no value at all, CLI and Tools -> Management Model show -1.

Comment 1 Heiko Braun 2013-10-15 08:31:46 UTC

Make sure it's reallu a UI issue. To me it's sounds like a server side problem

Comment 2 Martin Svehla 2013-10-15 08:45:22 UTC

Heiko,

When I go in CLI client to /subsystem=messaging/hornetq-server=default/discovery-group=dg-group1 and call

:write-attribute(name=initial-wait-timeout,value=1111111111111111111)

result is
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

and ls indeed shows attribute initial-wait-timeout set to that value.

If I go to web console after that, I see value -1 for that discovery group. When I enter edit mode the form shows 1111111111111111111 (correct value).

Comment 3 JBoss JIRA Server 2014-07-03 07:45:12 UTC

Heiko Braun <ike.braun> updated the status of jira HAL-439 to Coding In Progress

Comment 4 JBoss JIRA Server 2014-07-03 10:20:26 UTC

Heiko Braun <ike.braun> updated the status of jira HAL-439 to Resolved

Comment 7 Pavel Jelinek 2014-11-26 09:30:39 UTC

Should this still remain in POST state?

Comment 8 Pavel Jelinek 2014-12-05 15:17:33 UTC

For EAP 6.4.0.DR12 in webconsole numeric fields it seems that there is validation that avoids enter numeric values same or larger than 2^31 regardless if it is possible to enter such value via CLI.

Comment 9 Pavel Jelinek 2014-12-08 15:16:06 UTC

Try enter long value larger than 2^31 to initial-wait-timeout of some discovery group 
/profile=full/subsystem=messaging/hornetq-server=default/discovery-group=dgroup:write-attribute(name=initial-wait-timeout,value=123456789012345678)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main_server_group" => {"host" => {"master" => {
        "server-one" => {"response" => {
            "outcome" => "success",
            "response-headers" => {
                "operation-requires-restart" => true,
                "process-state" => "restart-required"
            }
        }},
        "server-two" => {"response" => {
            "outcome" => "success",
            "response-headers" => {
                "operation-requires-restart" => true,
                "process-state" => "restart-required"
            }
        }}
    }}}}
}
The operation vith the same value is not allowed in webconsole. You get 'Invalid numeric value' validation warning. Moreover if you have this value so large (e.g. updated via CLI as above) webconsole show you 0 as value of Initial Wait Timeout. The problem is probably caused by integer data type for this attribute in admin console instead of long.

Comment 10 JBoss JIRA Server 2015-04-28 11:09:38 UTC

Heiko Braun <ike.braun> updated the status of jira HAL-439 to Reopened

Comment 11 JBoss JIRA Server 2015-06-30 22:38:37 UTC

Harald Pehl <hpehl> updated the status of jira HAL-439 to Resolved

Comment 12 Harald Pehl 2015-06-30 22:39:55 UTC

Fixed in Ballroom 2.3.1

Comment 13 Mike McCune 2016-03-28 22:41:35 UTC

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions