Hello,
I have implemented a retry filter for CoAP protocol to handle
retransmission of Confirmable messages.
https://github.com/msangoi/mina/tree/retry
Thanks,
Manuel
Cool ! Thanks for contribution
Please create a JIRA and attach the patch to it.
On Wed, Oct 30, 2013 at 2:39 PM, Manu Sangoi manu.sangoi@gmail.comwrote:
Hello,
I have implemented a retry filter for CoAP protocol to handle
retransmission of Confirmable messages.
Hi I'm working on a multi threaded project that create about 200
simltaneous threads.
For each thread i have a mina connection to a server.
And sometimes when retrieving the response, the object response is null
Object response = null;
session.write(frame);
if
Le 10/30/13 10:40 AM, Joachim Rodrigues a écrit :
Hi I'm working on a multi threaded project that create about 200
simltaneous threads.
For each thread i have a mina connection to a server.
And sometimes when retrieving the response, the object response is null
Object response =
boolean await(long timeoutMillis)
throws InterruptedException
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/InterruptedException.html?is-external=true
Wait for the asynchronous operation to complete with the specified timeout.
Returns:true if the operation is completed.
So I
Your code is wrong because you swallow the interrupted exception, so you
will call getMessage even if you got a timeout condition hence the null
value returned.
Jeff
On Wed, Oct 30, 2013 at 10:40 AM, Joachim Rodrigues
rodrigues.joac...@gmail.com wrote:
Hi I'm working on a multi threaded
Thanks, I commited the contrib so no need of jira, it won't be lost ;)
--
Julien Vermillard http://people.apache.org/~jvermillard/
On Wed, Oct 30, 2013 at 10:30 AM, Ashish paliwalash...@gmail.com wrote:
Cool ! Thanks for contribution
Please create a JIRA and attach the patch to it.
On
why don't you implement a file locking mechanism ? it's the better and simplest
solution
Messaggio originale
Da: genti.t...@gmail.com
Data: 22-ott-2013 15.29
A: dev@mina.apache.org
Ogg: Re: locking files while being downloaded
The afterCommand will execute at the end rather. My issue is
as well know, fileoutputstream and randomaccessfile objects aren't thread
safe.So i if concurrent client sessions upload the same file concurrently (
e.g. while restarting a previous interrupted upload or malicious use as
client starting more uploads of the same file), the received file could have
File locking mechanism is probably a very good idea. It just has to
interact with events from FTP though.
On Wed, Oct 30, 2013 at 7:11 AM, seventy...@virgilio.it
seventy...@virgilio.it wrote:
why don't you implement a file locking mechanism ? it's the better and
simplest solution
10 matches
Mail list logo