beam-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré (JIRA) <j...@apache.org>
Subject [jira] [Updated] (BEAM-569) JMS IO should set maxNumRecords to Long.MAX_VALUE by default
Date Sat, 27 Aug 2016 12:01:20 GMT

     [ https://issues.apache.org/jira/browse/BEAM-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jean-Baptiste Onofré updated BEAM-569:
--------------------------------------
    Description: 
When using JmsIO this way:

{code}
JmsIO.read().withConnectionFactory(connectionFactory).withQueue("queue")
{/code}

the user expects to work in unbounded mode. However, as the {{maxNumRecords}} value is not
set by default in {{JmsIO}}, the default value set is {{0}} (as it's a {{long}}). It means
that the {{JmsIO.read()}} just doesn't consume any message and exit directly.

IMHO, it makes sense to define the {{maxNumRecords}} value to {{Long.MAX_VALUE}} by default.
Thanks to that, {{JmsIO.read()}} will really work in unbounded form.

  was:
Right now, the JMS IO source doesn't wait for new message on the JMS destination (it uses
{{receiveNoWait()}} method on the consumer).

I think, it's worth to give the possibility for the user to define the behavior.

I propose to introduce {{withTimeout()}} configuration on JMS IO:
- if the user defines {{-1}}, it means infinite timeout, so the reader will use {{consumer.receive()}}
and the source will wait for new messages on the destination
- if the user defines {{0}}, it means the current behavior (and default): the reader will
use {{consumer.receiveNoWait()}}.
- if the user defines any positive value, it's actually the timeout to wait for new messages:
the reader will use {{consumer.receive(timeout)}}.


> JMS IO should set maxNumRecords to Long.MAX_VALUE by default
> ------------------------------------------------------------
>
>                 Key: BEAM-569
>                 URL: https://issues.apache.org/jira/browse/BEAM-569
>             Project: Beam
>          Issue Type: Improvement
>          Components: sdk-java-extensions
>            Reporter: Jean-Baptiste Onofré
>            Assignee: Jean-Baptiste Onofré
>             Fix For: 0.3.0-incubating
>
>
> When using JmsIO this way:
> {code}
> JmsIO.read().withConnectionFactory(connectionFactory).withQueue("queue")
> {/code}
> the user expects to work in unbounded mode. However, as the {{maxNumRecords}} value is
not set by default in {{JmsIO}}, the default value set is {{0}} (as it's a {{long}}). It means
that the {{JmsIO.read()}} just doesn't consume any message and exit directly.
> IMHO, it makes sense to define the {{maxNumRecords}} value to {{Long.MAX_VALUE}} by default.
Thanks to that, {{JmsIO.read()}} will really work in unbounded form.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message