You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by huntc <hu...@mac.com> on 2010/01/15 14:41:18 UTC
requestBodyAndHeader and HEADER_CLOSE_SESSION_WHEN_COMPLETE
Hi there,
Is the following code valid... my goal is to ensure that the MINA connection
I'm using is closed upon having received a reply:
Object replyMessage = producerTemplate
.requestBodyAndHeader(
smsSenderEndpoint,
requestMessage,
MinaConsumer.HEADER_CLOSE_SESSION_WHEN_COMPLETE,
true);
The doco. implies that the above header value is useful in server style
scenarios hence my question around using a consuming template call.
I'd like to confirm whether it is necessary for me to specify this header in
the context of using a template; particularly if the same template is
invoked again to send another message very soon after receiving a reply to
the previous one.
Thanks.
Kind regards,
Christopher
--
View this message in context: http://old.nabble.com/requestBodyAndHeader-and-HEADER_CLOSE_SESSION_WHEN_COMPLETE-tp27175565p27175565.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: requestBodyAndHeader and HEADER_CLOSE_SESSION_WHEN_COMPLETE
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Jan 26, 2010 at 11:16 AM, huntc <hu...@mac.com> wrote:
>
> Hi Claus,
>
> I have now created a Cookbook recipe explaining this use case.
>
> http://cwiki.apache.org/confluence/display/CAMEL/Fine+Grained+Control+Over+a+Channel
>
I like the recipe, great work.
> Kind regards,
> Christopher
> --
> View this message in context: http://old.nabble.com/requestBodyAndHeader-and-HEADER_CLOSE_SESSION_WHEN_COMPLETE-tp27175565p27320438.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: requestBodyAndHeader and HEADER_CLOSE_SESSION_WHEN_COMPLETE
Posted by huntc <hu...@mac.com>.
Hi Claus,
I have now created a Cookbook recipe explaining this use case.
http://cwiki.apache.org/confluence/display/CAMEL/Fine+Grained+Control+Over+a+Channel
Kind regards,
Christopher
--
View this message in context: http://old.nabble.com/requestBodyAndHeader-and-HEADER_CLOSE_SESSION_WHEN_COMPLETE-tp27175565p27320438.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: requestBodyAndHeader and HEADER_CLOSE_SESSION_WHEN_COMPLETE
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Jan 23, 2010 at 8:41 PM, huntc <hu...@mac.com> wrote:
>
> Hi Claus,
>
> I'm happy to create a ticket of course, however I'm not clear on what the
> resolution is. I am not sure that implementing a "disconnect" URI option is
> the way to go though as per FTP. My use case is that I want to establish a
> connection, send multiple messages within a loop through that *same*
> connection and then close the connection.
>
> I do not think that I want to change my URI for just the last message
> sent... that sounds a little messy. I suppose a header value would get over
> this as per consuming messages from MINA and would be nicer programatically.
>
> However and most importantly, if I use a template then I do not think
> there's a guarantee that I'm going to send through the same connection each
> time I send a message in my loop i.e. if another thread decides also to send
> messages through the same URI then could it: (i) hijack the same connection;
> and (ii) potentially cause my subsequent messages to go over another
> connection? Neither of these two scenarios would be good.
>
> While we're figuring this out, is my usage of a Producer directly valid as a
> work-around?
>
Yes its a very good workaround as you invoke the stop method after use
which means it will terminate the session.
In fact you should not see this as a workaround as its using the API
as it was meant to be used. Its however often we use the higher level
API such as ProducerTemplate for those one-liners.
> Kind regards,
> Christopher
> --
> View this message in context: http://old.nabble.com/requestBodyAndHeader-and-HEADER_CLOSE_SESSION_WHEN_COMPLETE-tp27175565p27289240.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: requestBodyAndHeader and HEADER_CLOSE_SESSION_WHEN_COMPLETE
Posted by huntc <hu...@mac.com>.
Hi Claus,
I'm happy to create a ticket of course, however I'm not clear on what the
resolution is. I am not sure that implementing a "disconnect" URI option is
the way to go though as per FTP. My use case is that I want to establish a
connection, send multiple messages within a loop through that *same*
connection and then close the connection.
I do not think that I want to change my URI for just the last message
sent... that sounds a little messy. I suppose a header value would get over
this as per consuming messages from MINA and would be nicer programatically.
However and most importantly, if I use a template then I do not think
there's a guarantee that I'm going to send through the same connection each
time I send a message in my loop i.e. if another thread decides also to send
messages through the same URI then could it: (i) hijack the same connection;
and (ii) potentially cause my subsequent messages to go over another
connection? Neither of these two scenarios would be good.
While we're figuring this out, is my usage of a Producer directly valid as a
work-around?
Kind regards,
Christopher
--
View this message in context: http://old.nabble.com/requestBodyAndHeader-and-HEADER_CLOSE_SESSION_WHEN_COMPLETE-tp27175565p27289240.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: requestBodyAndHeader and HEADER_CLOSE_SESSION_WHEN_COMPLETE
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Jan 23, 2010 at 8:08 AM, huntc <hu...@mac.com> wrote:
>
> Hi guys,
>
> Turns out that I'm using MinaProducer and not MinaConsumer of course;
> MinaConsumer is the one that has the HEADER_CLOSE_SESSION_WHEN_COMPLETE
> logic and MinaProducer isn't so capable by the looks of it.
>
> I was hoping that stopping the template by calling its stop method would in
> turn cause the MinaProducer to close its session. It does not.
>
> I then reverted to the lower level method of creating a producer for my
> endpoint and then using the following logic:
>
>
> CamelContext camelContext = exchange.getContext();
>
> Endpoint endpoint = camelContext.getEndpoint(smsSenderEndpoint);
> Producer producer = endpoint.createProducer();
> producer.start();
>
> try {
> ...
>
> // For each message to send
> Exchange smsExchange = producer.createExchange();
> smsExchange.getIn().setBody(requestMessage);
> producer.process(smsExchange);
> Object replyMessage = smsExchange.getOut().getBody();
>
> …
>
> } finally {
> producer.stop();
> }
>
>
> Is this the best approach for sending out a stream of messages through the
> same channel and then ensuring that the channel is closed down; or should we
> be looking at some new functionality perhaps in the form of some header or
> method indicating that a session should be closed by the producer?
>
Yeah create a ticket in JIRA to allow closing the session after usage,
just as we have added to FTP which is called disconnect.
> Kind regards,
> Christopher
> --
> View this message in context: http://old.nabble.com/requestBodyAndHeader-and-HEADER_CLOSE_SESSION_WHEN_COMPLETE-tp27175565p27283994.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: requestBodyAndHeader and HEADER_CLOSE_SESSION_WHEN_COMPLETE
Posted by huntc <hu...@mac.com>.
Hi guys,
Turns out that I'm using MinaProducer and not MinaConsumer of course;
MinaConsumer is the one that has the HEADER_CLOSE_SESSION_WHEN_COMPLETE
logic and MinaProducer isn't so capable by the looks of it.
I was hoping that stopping the template by calling its stop method would in
turn cause the MinaProducer to close its session. It does not.
I then reverted to the lower level method of creating a producer for my
endpoint and then using the following logic:
CamelContext camelContext = exchange.getContext();
Endpoint endpoint = camelContext.getEndpoint(smsSenderEndpoint);
Producer producer = endpoint.createProducer();
producer.start();
try {
...
// For each message to send
Exchange smsExchange = producer.createExchange();
smsExchange.getIn().setBody(requestMessage);
producer.process(smsExchange);
Object replyMessage = smsExchange.getOut().getBody();
…
} finally {
producer.stop();
}
Is this the best approach for sending out a stream of messages through the
same channel and then ensuring that the channel is closed down; or should we
be looking at some new functionality perhaps in the form of some header or
method indicating that a session should be closed by the producer?
Kind regards,
Christopher
--
View this message in context: http://old.nabble.com/requestBodyAndHeader-and-HEADER_CLOSE_SESSION_WHEN_COMPLETE-tp27175565p27283994.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: requestBodyAndHeader and HEADER_CLOSE_SESSION_WHEN_COMPLETE
Posted by Claus Ibsen <cl...@gmail.com>.
Debug the code :)
You should see this in the DEBUG log
LOG.debug("Closing session when complete");
On Thu, Jan 21, 2010 at 11:49 AM, huntc <hu...@mac.com> wrote:
>
>
> Claus Ibsen-2 wrote:
>>
>> Yes you need to pass in this header every time you want to session closed.
>>
>
> I'm pretty convinced that this isn't happening for me despite passing in the
> header that I want the session closed when complete (which I presume is when
> I get a reply). Here's my log file:
>
>
> 2010-01-21 15:57:59,406 [lCalendarEvents] DEBUG
> lendarEventAttendeeSMSNotifier - Sending message to xxx: Reply to confirm
> meeting closed Thu, 21 Jan '10 03:35PM Scen 7 # 7
> 2010-01-21 15:57:59,409 [IoProcessor-1.2] INFO MinaProducer$ResponseHandler
> - [/192.168.0.200:9500] CREATED
> 2010-01-21 15:57:59,409 [IoProcessor-1.2] DEBUG ExecutorFilter
> - Launching thread for /192.168.0.200:9500
> 2010-01-21 15:57:59,410 [ MinaThreadPool] INFO MinaProducer$ResponseHandler
> - [/192.168.0.200:9500] OPENED
> 2010-01-21 15:57:59,410 [ MinaThreadPool] DEBUG ExecutorFilter
> - Exiting since queue is empty for /192.168.0.200:9500
> 2010-01-21 15:57:59,410 [lCalendarEvents] INFO MinaProducer$ResponseHandler
> - [/192.168.0.200:9500] WRITE:
> au.com.blueglue.bluegluesmsprotocol.SendSMS@8e1a0d01
> 2010-01-21 15:57:59,411 [IoProcessor-1.2] DEBUG ExecutorFilter
> - Launching thread for /192.168.0.200:9500
> 2010-01-21 15:57:59,411 [ MinaThreadPool] INFO MinaProducer$ResponseHandler
> - [/192.168.0.200:9500] SENT:
> au.com.blueglue.bluegluesmsprotocol.SendSMS@8e1a0d01
> 2010-01-21 15:57:59,411 [ MinaThreadPool] DEBUG ExecutorFilter
> - Exiting since queue is empty for /192.168.0.200:9500
> 2010-01-21 15:58:10,979 [IoProcessor-1.2] DEBUG ExecutorFilter
> - Launching thread for /192.168.0.200:9500
> 2010-01-21 15:58:10,979 [ MinaThreadPool] INFO MinaProducer$ResponseHandler
> - [/192.168.0.200:9500] RECEIVED:
> au.com.blueglue.bluegluesmsprotocol.TransmittedSMS@8e1a0d01
> 2010-01-21 15:58:10,979 [ MinaThreadPool] DEBUG ExecutorFilter
> - Exiting since queue is empty for /192.168.0.200:9500
> 2010-01-21 15:58:10,979 [lCalendarEvents] DEBUG
> lendarEventAttendeeSMSNotifier - Message sent
> 2010-01-21 15:58:10,980 [lCalendarEvents] DEBUG
> lendarEventAttendeeSMSNotifier - Sending message to yyy: Reply to confirm
> meeting closed Thu, 21 Jan '10 03:35PM Scen 7 # 7
> 2010-01-21 15:58:10,980 [lCalendarEvents] INFO MinaProducer$ResponseHandler
> - [/192.168.0.200:9500] WRITE:
> au.com.blueglue.bluegluesmsprotocol.SendSMS@808819c0
> 2010-01-21 15:58:10,981 [IoProcessor-1.2] DEBUG ExecutorFilter
> - Launching thread for /192.168.0.200:9500
> 2010-01-21 15:58:10,981 [ MinaThreadPool] INFO MinaProducer$ResponseHandler
> - [/192.168.0.200:9500] SENT:
> au.com.blueglue.bluegluesmsprotocol.SendSMS@808819c0
> 2010-01-21 15:58:10,981 [ MinaThreadPool] DEBUG ExecutorFilter
> - Exiting since queue is empty for /192.168.0.200:9500
> 2010-01-21 15:58:10,983 [IoProcessor-1.2] DEBUG ExecutorFilter
> - Launching thread for /192.168.0.200:9500
> ...
>
>
> After the received event at 2010-01-21 15:58:10,979, I was hoping that the
> socket would be closed. As you can see there is no trace in the log of the
> socket being closed.
>
> Is this a bug or am I not doing something quite right. Here's my code again:
>
>
> Object replyMessage = producerTemplate
> .requestBodyAndHeader(
> smsSenderEndpoint,
> requestMessage,
> MinaConsumer.HEADER_CLOSE_SESSION_WHEN_COMPLETE,
> true);
>
>
> The above template instance is called twice in succession as shown by the
> "Sending message to" entries.
>
> Thanks for your help.
>
> Kind regards,
> Christopher
> --
> View this message in context: http://old.nabble.com/requestBodyAndHeader-and-HEADER_CLOSE_SESSION_WHEN_COMPLETE-tp27175565p27255912.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: requestBodyAndHeader and HEADER_CLOSE_SESSION_WHEN_COMPLETE
Posted by huntc <hu...@mac.com>.
Claus Ibsen-2 wrote:
>
> Yes you need to pass in this header every time you want to session closed.
>
I'm pretty convinced that this isn't happening for me despite passing in the
header that I want the session closed when complete (which I presume is when
I get a reply). Here's my log file:
2010-01-21 15:57:59,406 [lCalendarEvents] DEBUG
lendarEventAttendeeSMSNotifier - Sending message to xxx: Reply to confirm
meeting closed Thu, 21 Jan '10 03:35PM Scen 7 # 7
2010-01-21 15:57:59,409 [IoProcessor-1.2] INFO MinaProducer$ResponseHandler
- [/192.168.0.200:9500] CREATED
2010-01-21 15:57:59,409 [IoProcessor-1.2] DEBUG ExecutorFilter
- Launching thread for /192.168.0.200:9500
2010-01-21 15:57:59,410 [ MinaThreadPool] INFO MinaProducer$ResponseHandler
- [/192.168.0.200:9500] OPENED
2010-01-21 15:57:59,410 [ MinaThreadPool] DEBUG ExecutorFilter
- Exiting since queue is empty for /192.168.0.200:9500
2010-01-21 15:57:59,410 [lCalendarEvents] INFO MinaProducer$ResponseHandler
- [/192.168.0.200:9500] WRITE:
au.com.blueglue.bluegluesmsprotocol.SendSMS@8e1a0d01
2010-01-21 15:57:59,411 [IoProcessor-1.2] DEBUG ExecutorFilter
- Launching thread for /192.168.0.200:9500
2010-01-21 15:57:59,411 [ MinaThreadPool] INFO MinaProducer$ResponseHandler
- [/192.168.0.200:9500] SENT:
au.com.blueglue.bluegluesmsprotocol.SendSMS@8e1a0d01
2010-01-21 15:57:59,411 [ MinaThreadPool] DEBUG ExecutorFilter
- Exiting since queue is empty for /192.168.0.200:9500
2010-01-21 15:58:10,979 [IoProcessor-1.2] DEBUG ExecutorFilter
- Launching thread for /192.168.0.200:9500
2010-01-21 15:58:10,979 [ MinaThreadPool] INFO MinaProducer$ResponseHandler
- [/192.168.0.200:9500] RECEIVED:
au.com.blueglue.bluegluesmsprotocol.TransmittedSMS@8e1a0d01
2010-01-21 15:58:10,979 [ MinaThreadPool] DEBUG ExecutorFilter
- Exiting since queue is empty for /192.168.0.200:9500
2010-01-21 15:58:10,979 [lCalendarEvents] DEBUG
lendarEventAttendeeSMSNotifier - Message sent
2010-01-21 15:58:10,980 [lCalendarEvents] DEBUG
lendarEventAttendeeSMSNotifier - Sending message to yyy: Reply to confirm
meeting closed Thu, 21 Jan '10 03:35PM Scen 7 # 7
2010-01-21 15:58:10,980 [lCalendarEvents] INFO MinaProducer$ResponseHandler
- [/192.168.0.200:9500] WRITE:
au.com.blueglue.bluegluesmsprotocol.SendSMS@808819c0
2010-01-21 15:58:10,981 [IoProcessor-1.2] DEBUG ExecutorFilter
- Launching thread for /192.168.0.200:9500
2010-01-21 15:58:10,981 [ MinaThreadPool] INFO MinaProducer$ResponseHandler
- [/192.168.0.200:9500] SENT:
au.com.blueglue.bluegluesmsprotocol.SendSMS@808819c0
2010-01-21 15:58:10,981 [ MinaThreadPool] DEBUG ExecutorFilter
- Exiting since queue is empty for /192.168.0.200:9500
2010-01-21 15:58:10,983 [IoProcessor-1.2] DEBUG ExecutorFilter
- Launching thread for /192.168.0.200:9500
...
After the received event at 2010-01-21 15:58:10,979, I was hoping that the
socket would be closed. As you can see there is no trace in the log of the
socket being closed.
Is this a bug or am I not doing something quite right. Here's my code again:
Object replyMessage = producerTemplate
.requestBodyAndHeader(
smsSenderEndpoint,
requestMessage,
MinaConsumer.HEADER_CLOSE_SESSION_WHEN_COMPLETE,
true);
The above template instance is called twice in succession as shown by the
"Sending message to" entries.
Thanks for your help.
Kind regards,
Christopher
--
View this message in context: http://old.nabble.com/requestBodyAndHeader-and-HEADER_CLOSE_SESSION_WHEN_COMPLETE-tp27175565p27255912.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: requestBodyAndHeader and HEADER_CLOSE_SESSION_WHEN_COMPLETE
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Jan 15, 2010 at 2:41 PM, huntc <hu...@mac.com> wrote:
>
> Hi there,
>
> Is the following code valid... my goal is to ensure that the MINA connection
> I'm using is closed upon having received a reply:
>
> Object replyMessage = producerTemplate
> .requestBodyAndHeader(
> smsSenderEndpoint,
> requestMessage,
> MinaConsumer.HEADER_CLOSE_SESSION_WHEN_COMPLETE,
> true);
>
> The doco. implies that the above header value is useful in server style
> scenarios hence my question around using a consuming template call.
>
> I'd like to confirm whether it is necessary for me to specify this header in
> the context of using a template; particularly if the same template is
> invoked again to send another message very soon after receiving a reply to
> the previous one.
>
Yes you need to pass in this header every time you want to session closed.
> Thanks.
>
> Kind regards,
> Christopher
> --
> View this message in context: http://old.nabble.com/requestBodyAndHeader-and-HEADER_CLOSE_SESSION_WHEN_COMPLETE-tp27175565p27175565.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus