[configuration] StackOverflow when using a custom reloading strategy

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[configuration] StackOverflow when using a custom reloading strategy

Nicolas De Loof-3

Hello,

I'm trying to setup a custom reloading strategy (based on JMX management
command).
My reloadingRequired() implementation uses an internal boolean to ask
for reload. On reloadingPerformed(), I set this boolean to false.

I get StackOverflowException because addPropertyDirect() method uses
getProperty, that itself check for reload. This requires me to set my
internal boolean to false at first reloadingRequired invocation after
reloading has been asked.

IMHO AbstractFileConfiguration should use a 'reloading' flag to avoid
such case.

It would also be great not to lock access to properties during file
reload. I've made a simple configuration tool that was using a temporary
Map during loading and replaced the internal one when reload succeded.
In current implementation, I think if an IOException occurs, the
properties have allready been cleared, and the configuration is broken.

Nico.

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient,  you are not authorized to read, print, retain, copy, disseminate,  distribute, or use this message or any part thereof. If you receive this  message in error, please notify the sender immediately and delete all  copies of this message.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[httpclient] how to prevent slow connection from hanging up my application?

Christian Hufgard
Hi,

to prevent our application from suffering when dealing with slow systems, we
are using HttpClient.setTimeout() and HttpClient.setConnectionTimeout().
Till today I tought, this would be enough.

Now, during some testing, I found out, that we have a legacy system that
sometime tends to be really slow. We have data transfer rates below 1kB at
documentsizes more then 60k.

Is there any way, to define an abort time? E.g. "read 20 seconds, if data is
still missing forget about it"?.

At the moment I tend to use something like this:

        long start = System.currentTimeMillis();
        int readTimeout = 20000;
               
        ByteArrayOutputStream dataStream = new ByteArrayOutputStream();
        BufferedInputStream in = new BufferedInputStream(s.getInputStream());
        byte[] data = new byte[1024];
        int avail;
        while ((avail = in.read(data, 0, 1024)) != -1) {
                dataStream.write(data, 0, avail);
                long now = System.currentTimeMillis();
                if (now - start > readTimeout) {
                        throw new IOException("Read timeout!");
                }
        }

Is there any smarter way, that I just did not find?



Christian

--
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [httpclient] how to prevent slow connection from hanging up my application?

olegk
HttpMethod#abort() may be what you want. This method is threading safe,
so it can be safely called from an observer thread that aborts the
worker thread if it fails to terminate wintin the desired period of time

Hope this helps

Oleg


On Fri, Jul 29, 2005 at 03:38:57PM +0200, Christian Hufgard wrote:

> Hi,
>
> to prevent our application from suffering when dealing with slow systems, we
> are using HttpClient.setTimeout() and HttpClient.setConnectionTimeout().
> Till today I tought, this would be enough.
>
> Now, during some testing, I found out, that we have a legacy system that
> sometime tends to be really slow. We have data transfer rates below 1kB at
> documentsizes more then 60k.
>
> Is there any way, to define an abort time? E.g. "read 20 seconds, if data is
> still missing forget about it"?.
>
> At the moment I tend to use something like this:
>
> long start = System.currentTimeMillis();
> int readTimeout = 20000;
>
> ByteArrayOutputStream dataStream = new ByteArrayOutputStream();
> BufferedInputStream in = new BufferedInputStream(s.getInputStream());
> byte[] data = new byte[1024];
> int avail;
> while ((avail = in.read(data, 0, 1024)) != -1) {
> dataStream.write(data, 0, avail);
> long now = System.currentTimeMillis();
> if (now - start > readTimeout) {
> throw new IOException("Read timeout!");
> }
> }
>
> Is there any smarter way, that I just did not find?
>
>
>
> Christian
>
> --
> GMX DSL = Maximale Leistung zum minimalen Preis!
> 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] StackOverflow when using a custom reloading strategy

Emmanuel Bourg-3
In reply to this post by Nicolas De Loof-3
Nicolas De Loof wrote:
> I'm trying to setup a custom reloading strategy (based on JMX management
> command).
> My reloadingRequired() implementation uses an internal boolean to ask
> for reload. On reloadingPerformed(), I set this boolean to false.

This boolean is a property of the configuration I guess, I suggest
implementing this flag as a field of your reloading strategy instead.

> It would also be great not to lock access to properties during file
> reload. I've made a simple configuration tool that was using a temporary
> Map during loading and replaced the internal one when reload succeded.
> In current implementation, I think if an IOException occurs, the
> properties have allready been cleared, and the configuration is broken.

This issue isn't really caused by the locking, the reload()
implementation is just unable to recover if it fails. This is on our
todo list, but contributions are welcome.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re[2]: [httpclient] how to prevent slow connection from hanging up my application?

Christian Hufgard
In reply to this post by olegk
Hi Oleg,

thank you for that hint, but I think this it not, what I am looking
for.

Is there really nothing like "setReadTimeout(long timeout)?

Christian


Friday, July 29, 2005, 3:46:06 PM, you wrote:

> HttpMethod#abort() may be what you want. This method is threading safe,
> so it can be safely called from an observer thread that aborts the
> worker thread if it fails to terminate wintin the desired period of time

> Hope this helps

> Oleg


> On Fri, Jul 29, 2005 at 03:38:57PM +0200, Christian Hufgard wrote:
>> Hi,
>>
>> to prevent our application from suffering when dealing with slow systems, we
>> are using HttpClient.setTimeout() and
>> HttpClient.setConnectionTimeout().
>> Till today I tought, this would be enough.
>>
>> Now, during some testing, I found out, that we have a legacy system that
>> sometime tends to be really slow. We have data transfer rates below 1kB at
>> documentsizes more then 60k.
>>
>> Is there any way, to define an abort time? E.g. "read 20 seconds, if data is
>> still missing forget about it"?.
>>
>> At the moment I tend to use something like this:
>>
>>       long start = System.currentTimeMillis();
>>       int readTimeout = 20000;
>>              
>>       ByteArrayOutputStream dataStream = new ByteArrayOutputStream();
>>       BufferedInputStream in = new
>> BufferedInputStream(s.getInputStream());
>>       byte[] data = new byte[1024];
>>       int avail;
>>       while ((avail = in.read(data, 0, 1024)) != -1) {
>>               dataStream.write(data, 0, avail);
>>               long now = System.currentTimeMillis();
>>               if (now - start > readTimeout) {
>>                       throw new IOException("Read timeout!");
>>               }
>>       }
>>
>> Is there any smarter way, that I just did not find?
>>
>>
>>
>> Christian
>>
>> --
>> GMX DSL = Maximale Leistung zum minimalen Preis!
>> 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail:
>> [hidden email]
>>
>>

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail:
> [hidden email]



--
Best regards,
 Christian                            mailto:[hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [httpclient] how to prevent slow connection from hanging up my application?

olegk
On Fri, Jul 29, 2005 at 06:21:23PM +0200, Christian Hufgard wrote:
> Hi Oleg,
>
> thank you for that hint, but I think this it not, what I am looking
> for.
>
> Is there really nothing like "setReadTimeout(long timeout)?
>

Really not. There's also really nothing like
"doThatBoringJobForMe()", which I'd love to have provided for me ;-)

There's a method to set the so called socket timeout, which is the
maximum period of inactivity between two consecutive read operations.
If you need a means to abort the request if it has not completed within
a given time limit, even if the data keeps trickling in, you have to
provide it yourself

Oleg


> Christian
>
>
> Friday, July 29, 2005, 3:46:06 PM, you wrote:
>
> > HttpMethod#abort() may be what you want. This method is threading safe,
> > so it can be safely called from an observer thread that aborts the
> > worker thread if it fails to terminate wintin the desired period of time
>
> > Hope this helps
>
> > Oleg
>
>
> > On Fri, Jul 29, 2005 at 03:38:57PM +0200, Christian Hufgard wrote:
> >> Hi,
> >>
> >> to prevent our application from suffering when dealing with slow systems, we
> >> are using HttpClient.setTimeout() and
> >> HttpClient.setConnectionTimeout().
> >> Till today I tought, this would be enough.
> >>
> >> Now, during some testing, I found out, that we have a legacy system that
> >> sometime tends to be really slow. We have data transfer rates below 1kB at
> >> documentsizes more then 60k.
> >>
> >> Is there any way, to define an abort time? E.g. "read 20 seconds, if data is
> >> still missing forget about it"?.
> >>
> >> At the moment I tend to use something like this:
> >>
> >>       long start = System.currentTimeMillis();
> >>       int readTimeout = 20000;
> >>              
> >>       ByteArrayOutputStream dataStream = new ByteArrayOutputStream();
> >>       BufferedInputStream in = new
> >> BufferedInputStream(s.getInputStream());
> >>       byte[] data = new byte[1024];
> >>       int avail;
> >>       while ((avail = in.read(data, 0, 1024)) != -1) {
> >>               dataStream.write(data, 0, avail);
> >>               long now = System.currentTimeMillis();
> >>               if (now - start > readTimeout) {
> >>                       throw new IOException("Read timeout!");
> >>               }
> >>       }
> >>
> >> Is there any smarter way, that I just did not find?
> >>
> >>
> >>
> >> Christian
> >>
> >> --
> >> GMX DSL = Maximale Leistung zum minimalen Preis!
> >> 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail:
> >> [hidden email]
> >>
> >>
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail:
> > [hidden email]
>
>
>
> --
> Best regards,
>  Christian                            mailto:[hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]