Re: does camel http4 clear the attachments of a message

2018-01-16 Thread Claus Ibsen 
So what do you have in those attachments and why do you want to keep
them? Where do you use them later? Can you tell more about this.

And you can take a look at content enricher eip to do the get call
where you can "merge" any response from the http call to your current
message and therefore control to keep the attachments and whatelse you
want.

On Tue, Jan 16, 2018 at 11:08 PM, Ronny Aerts  wrote:
> Hello camel user community,
>
>
> It seems that the camel http4 component clears/removes my existing camel 
> message attachments during a http get operation.
>
> Can this be confirmed?
>
> Can I avoid this?
>
>
> --
>
> vriendelijke groeten,
> Ronny Aerts – Intris nv – Wapenstilstandlaan 
> 47, 2600 Berchem, België
> Product Owner Integrations / Integrations Manager
>
> Prince II certified – 
> ITIL
>  certified
>
> Tel: +32-3-326.50.75
>
>
> Intris nv
> Wapenstilstandlaan 47
> B-2600 Berchem  Tel.  +32 3 326 50 75
> Fax  +32 3 326 42 23
> www.intris.be
> DISCLAIMER
> This is an e-mail from Intris. The information contained in this 
> communication is intended solely for use by the individual or entity to whom 
> it is addressed.
> Use of this communication by others is prohibited. If the e-mail message was 
> sent to you by mistake, please notify 
> supp...@intris.be, destroy it without reading, 
> using, copying or disclosing its contents to any other person.
> We accept no liability for damage related to data and/or documents which are 
> communicated by electronic mail.



-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

does camel http4 clear the attachments of a message

2018-01-16 Thread Ronny Aerts 
Hello camel user community,


It seems that the camel http4 component clears/removes my existing camel 
message attachments during a http get operation.

Can this be confirmed?

Can I avoid this?


--

vriendelijke groeten,
Ronny Aerts – Intris nv – Wapenstilstandlaan 47, 
2600 Berchem, België
Product Owner Integrations / Integrations Manager

Prince II certified – 
ITIL
 certified

Tel: +32-3-326.50.75


Intris nv
Wapenstilstandlaan 47
B-2600 Berchem  Tel.  +32 3 326 50 75
Fax  +32 3 326 42 23
www.intris.be
DISCLAIMER
This is an e-mail from Intris. The information contained in this communication 
is intended solely for use by the individual or entity to whom it is addressed.
Use of this communication by others is prohibited. If the e-mail message was 
sent to you by mistake, please notify 
supp...@intris.be, destroy it without reading, using, 
copying or disclosing its contents to any other person.
We accept no liability for damage related to data and/or documents which are 
communicated by electronic mail.

Re: File idempotent store problem

2018-01-16 Thread Claus Ibsen 
Hi

Yeah I can see the point that its better to have the default
implementation work better. I have reworked the implementation so the
file store and cache are independent and the cache is only used for
quick lookup. Also the default sizes of the file store has been
increased to allow storing more entries, and it now "free space" by
deleting the oldest 1000 entries (all configurable).



On Wed, Jan 3, 2018 at 8:51 PM, Krzysztof Hołdanowicz
 wrote:
> Hi,
>
> regarding CAMEL-12058 I don't know if you are aware of all consequences of
> wrong order in the idempotent file store.
> The wrong order in the file is not the problem itself as long as elemens
> are added and eviceted on runtime, because caffeine provides an api for
> ordering like:
>
>- @Override public Map coldest(int limit)
>- @Override public Map hottest(int limit)
>- @Override public Map oldest(int limit),
>- @Override public Map youngest(int limit) )
>
> however the consequences of this appears after RESTART. The memory cache
> does not contain the proper entries (in case of reaching the max limit
> size) because it does not load elements from hottest to coldest but with
> the file entries order hence some of the files are consumed multiple times.
> It means that current implementation of file idempotent store is not usable
> at all anymore. Ignoring the issue (CAMEL-12058) means that Camel library
> does not provide any implementation of idempotent file store as the current
> behaviour is completely wrong and causes consuming multiple times the same
> file after reaching max size limit and after restarting application.
>
>
> Regards
> Kris
>
> sob., 2 gru 2017 o 15:14 użytkownik Krzysztof Hołdanowicz <
> holdanow...@gmail.com> napisał:
>
>> I don't know if I understood you correctly.
>> Instead of looping via cache.keySet() you mean looping via:
>> Map.Entry entry : cache.entrySet() or cache.foreach((k, v)
>> -> {...})?
>>
>> If yes what is the difference? Isn't it the same unordered collection?
>> If Caffeince returns unordered collection how we can get ordered entries?
>> Isn't it related with:
>> https://github.com/ben-manes/caffeine/issues/86
>>
>> Shouldn't we use a kind of LinkedHashMap implementation?
>>
>> Regards
>> Kris
>>
>> wt., 28 lis 2017 o 18:40 użytkownik Claus Ibsen-2 [via Camel] <
>> ml+s465427n5815878...@n5.nabble.com> napisał:
>>
>>> Hi
>>>
>>> Ah well spotted.
>>> I think we should for loop via Map.Entry (or (k,v) via lambda) which I
>>> think will be in the correct order.
>>>
>>> You are welcome to log a JIRA. And also work on unit test and patch.
>>> http://camel.apache.org/contributing
>>>
>>> On Tue, Nov 28, 2017 at 8:55 AM, Krzysztof Hołdanowicz
>>> <[hidden email] >
>>> wrote:
>>>
>>> > Hi all,
>>> >
>>> > I recently noticed that there is wrong entry order in file using
>>> > FileIdempotentRepository implementation.
>>> > The effect is that instead of having order like:
>>> >
>>> > file1.txt.20171123
>>> > file2.txt.20171123
>>> > file1.txt.20171124
>>> > file3.txt.20171125
>>> > file2.txt.20171126
>>> >
>>> > we have:
>>> >
>>> > file1.txt.20171123
>>> > file1.txt.20171124
>>> > file2.txt.20171123
>>> > file2.txt.20171126
>>> > file3.txt.20171125
>>> >
>>> > where date extension represents order in which particular file was
>>> consumed
>>> > by the idempotent file consumer.
>>> > As a consequence instead of initializing memory cache with newest
>>> values,
>>> > it is initialized (probably) based on hash function from truncStore
>>> method
>>> > and we consume same file more than once:
>>> >
>>> > protected void trunkStore() {
>>> > LOG.info("Trunking idempotent filestore: {}", fileStore);
>>> > FileOutputStream fos = null;
>>> > try {
>>> > fos = new FileOutputStream(fileStore);
>>> > for (String key : *cache.keySet()*) {
>>> > fos.write(key.getBytes());
>>> > fos.write(STORE_DELIMITER.getBytes());
>>> > }
>>> > } catch (IOException e) {
>>> > throw ObjectHelper.wrapRuntimeCamelException(e);
>>> > } finally {
>>> > IOHelper.close(fos, "Trunking file idempotent repository",
>>> LOG);
>>> > }
>>> > }
>>> >
>>> > LRUCache:
>>> >
>>> > @Override
>>> > public Set keySet() {
>>> > return map.keySet();
>>> > }
>>> >
>>> > where previously it was:
>>> >
>>> > @Override
>>> > public Set keySet() {
>>> > return map.*ascendingKeySet*();
>>> > }
>>> >
>>> > Regards
>>> > Kris
>>> > --
>>> >
>>> > Pozdrawiam
>>> >
>>> > Krzysztof Hołdanowicz
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>>>
>>> --
>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>>