Bug 1018792 - Value overflow when entering large numeric value to form
Summary: Value overflow when entering large numeric value to form
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web Console
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: DR0
: EAP 6.4.0
Assignee: Harald Pehl
QA Contact: Pavel Jelinek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-14 12:20 UTC by Martin Svehla
Modified: 2019-08-19 12:47 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-19 12:47:48 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker HAL-439 0 Major Resolved Value overflow when entering large numeric value to form 2015-09-25 10:42:25 UTC

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


Note You need to log in before you can comment on or make changes to this bug.