You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by georgiosgeorgiadis <ge...@yahoo.co.uk> on 2008/03/04 14:53:29 UTC

Re: Camel TCP receiver endpoint

I have found out that the message properties and headers soes not seem to be
passed when using MINA TCP communication. In direct pojo or bean, everything
seems working.

Regards

Georgios


georgiosgeorgiadis wrote:
> 
> I am quite new to Camel, but I will need to use camel for implementing the
> following requirement:
> 
> I will need a component to be listening to a specific TCP port. Do I need
> to have a custom written TCP server which will serve the TCP component, or
> Camel can automatically wrap my component with a Camel TCP listener
> (server) using some type of constructor? For example I have the component:
> 
> public class MyComponent{
>   public void doSomething(){
>   }
> }
> 
> possible Camel TCP wrapper
> 
> Enpoint p  = new CamelTCPEndpoint("localhost",5555,new MyComponent());
> p.start();
> 
> My question is, does something like that exist or do I have to implement
> my own custom TCP servers/ listeners for my components? The general
> requirement is to have a component which calls a camel sender endpont
> which connects synchronously to a camel receiver TCP endpoint which
> propages the call to a component and send a reply all the way back to the
> sender, basically loosely coupled communication/routing between different
> environments.
> 
> I am trying to reduce communication implementation to the minimum and just
> use configurations loaded from a file or repository.
> 
> Thank you in advance
> 
> Georgios
> 

-- 
View this message in context: http://www.nabble.com/Camel-TCP-receiver-endpoint-tp15430834s22882p15827541.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Camel TCP receiver endpoint

Posted by georgiosgeorgiadis <ge...@yahoo.co.uk>.
Hi,

I have created a JIRA issue 383 and I have included the source files with my
fix as well as a junit test case.

Hope that helps.

Thanks

Georgios


davsclaus wrote:
> 
> Hi George
> 
> The best way to supply patches etc is to create a new ticket in JIRA
> (issue tracker)
> http://activemq.apache.org/camel/support.html
> 
> Then its not lost in this forum where people tend to read only the new
> posts.
> 
> As I am supplying quite a lot of patches to the MINA component lately I
> could take a look at your patches and get it into the core Camel.
> 
> I hear you point about just using the standard camel-mina component you
> will be able to send messages over the network and not lose your header
> and other properties on the exchange itself. 
> 
> So please create a JIRA and supply your patches and other files and we can
> go from there.
> 
> /Claus
> 
> 
> georgiosgeorgiadis wrote:
>> 
>> Hi Claus,
>> 
>> Thanks again.
>> 
>> We would prefer to use all camel components in a simple and transparent
>> way, of course.
>> Thus we would prefer that a patch especially for mina-camel component is
>> applied as a patch into Camel itself.
>> 
>> I have made the modifications myself in the local snapshot of Camel 1.2.0
>> here, which is the way for me to apply it in Camel? I can send my changes
>> in which specific classes in this forum or not?
>> 
>> Best regards
>> 
>> Georgios
>> 
>> 
>> 
>> davsclaus wrote:
>>> 
>>> Gerorge
>>> 
>>> Have you tried to use your own codec? There is a codec parameter to the
>>> uri configuration of camel routes.
>>> 
>>> The codec is then your Mina codec class where you can do the
>>> encode/decode where you can include the headers and properties from the
>>> exchange.
>>> 
>>> I am however not sure if using this codec it gives you access to the
>>> exchange in your subclass?
>>> 
>>> Another approach is to do your own data format, there is some examples
>>> in Camel where you can create your data formatter and annotate them.
>>> Then you can have your dataforma POJO class that holds the body, header
>>> and properties.
>>> 
>>> You are ofcourse welcome to try to create a patch for camel that
>>> includes the header and properties out-of-the-box. It is however not so
>>> easy as the raw TCP protocol is not a protocol that supports metadata as
>>> headers and properties = everything is one long binary stream. Unlike
>>> eg. messaging such as JMS.
>>> 
>>> 
>>> /Claus
>>> 
>>> 
>>> georgiosgeorgiadis wrote:
>>>> 
>>>> Hi Claus,
>>>> 
>>>> Yes, the requirement is that we connect to a local or TCP repository
>>>> with the ability to switch from the one or the other only with
>>>> configuration changes. The thing is that we specify some of the stuff
>>>> in the headers and the properties and they don't seem to be passed when
>>>> I use mina tcp camel endpoint.
>>>> 
>>>> Regards
>>>> 
>>>> Georgios
>>>> 
>>>> 
>>>> davsclaus wrote:
>>>>> 
>>>>> Hi George
>>>>> 
>>>>> camel-mina does only support marshalling the body content. (in.body)
>>>>> What is you use-case for using camel-mina to send messages that
>>>>> contains headers and properties as well?
>>>>> 
>>>>> /Claus
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Camel-TCP-receiver-endpoint-tp15430834s22882p16010119.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Camel TCP receiver endpoint

Posted by davsclaus <ci...@yahoo.dk>.
Hi George

The best way to supply patches etc is to create a new ticket in JIRA (issue
tracker)
http://activemq.apache.org/camel/support.html

Then its not lost in this forum where people tend to read only the new
posts.

As I am supplying quite a lot of patches to the MINA component lately I
could take a look at your patches and get it into the core Camel.

I hear you point about just using the standard camel-mina component you will
be able to send messages over the network and not lose your header and other
properties on the exchange itself. 

So please create a JIRA and supply your patches and other files and we can
go from there.

/Claus


georgiosgeorgiadis wrote:
> 
> Hi Claus,
> 
> Thanks again.
> 
> We would prefer to use all camel components in a simple and transparent
> way, of course.
> Thus we would prefer that a patch especially for mina-camel component is
> applied as a patch into Camel itself.
> 
> I have made the modifications myself in the local snapshot of Camel 1.2.0
> here, which is the way for me to apply it in Camel? I can send my changes
> in which specific classes in this forum or not?
> 
> Best regards
> 
> Georgios
> 
> 
> 
> davsclaus wrote:
>> 
>> Gerorge
>> 
>> Have you tried to use your own codec? There is a codec parameter to the
>> uri configuration of camel routes.
>> 
>> The codec is then your Mina codec class where you can do the
>> encode/decode where you can include the headers and properties from the
>> exchange.
>> 
>> I am however not sure if using this codec it gives you access to the
>> exchange in your subclass?
>> 
>> Another approach is to do your own data format, there is some examples in
>> Camel where you can create your data formatter and annotate them. Then
>> you can have your dataforma POJO class that holds the body, header and
>> properties.
>> 
>> You are ofcourse welcome to try to create a patch for camel that includes
>> the header and properties out-of-the-box. It is however not so easy as
>> the raw TCP protocol is not a protocol that supports metadata as headers
>> and properties = everything is one long binary stream. Unlike eg.
>> messaging such as JMS.
>> 
>> 
>> /Claus
>> 
>> 
>> georgiosgeorgiadis wrote:
>>> 
>>> Hi Claus,
>>> 
>>> Yes, the requirement is that we connect to a local or TCP repository
>>> with the ability to switch from the one or the other only with
>>> configuration changes. The thing is that we specify some of the stuff in
>>> the headers and the properties and they don't seem to be passed when I
>>> use mina tcp camel endpoint.
>>> 
>>> Regards
>>> 
>>> Georgios
>>> 
>>> 
>>> davsclaus wrote:
>>>> 
>>>> Hi George
>>>> 
>>>> camel-mina does only support marshalling the body content. (in.body)
>>>> What is you use-case for using camel-mina to send messages that
>>>> contains headers and properties as well?
>>>> 
>>>> /Claus
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Camel-TCP-receiver-endpoint-tp15430834s22882p16001963.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Camel TCP receiver endpoint

Posted by georgiosgeorgiadis <ge...@yahoo.co.uk>.
Hi Claus,

Thanks again.

We would prefer to use all camel components in a simple and transparent way,
of course.
Thus we would prefer that a patch especially for mina-camel component is
applied as a patch into Camel itself.

I have made the modifications myself in the local snapshot of Camel 1.2.0
here, which is the way for me to apply it in Camel? I can send my changes in
which specific classes in this forum or not?

Best regards

Georgios



davsclaus wrote:
> 
> Gerorge
> 
> Have you tried to use your own codec? There is a codec parameter to the
> uri configuration of camel routes.
> 
> The codec is then your Mina codec class where you can do the encode/decode
> where you can include the headers and properties from the exchange.
> 
> I am however not sure if using this codec it gives you access to the
> exchange in your subclass?
> 
> Another approach is to do your own data format, there is some examples in
> Camel where you can create your data formatter and annotate them. Then you
> can have your dataforma POJO class that holds the body, header and
> properties.
> 
> You are ofcourse welcome to try to create a patch for camel that includes
> the header and properties out-of-the-box. It is however not so easy as the
> raw TCP protocol is not a protocol that supports metadata as headers and
> properties = everything is one long binary stream. Unlike eg. messaging
> such as JMS.
> 
> 
> /Claus
> 
> 
> georgiosgeorgiadis wrote:
>> 
>> Hi Claus,
>> 
>> Yes, the requirement is that we connect to a local or TCP repository with
>> the ability to switch from the one or the other only with configuration
>> changes. The thing is that we specify some of the stuff in the headers
>> and the properties and they don't seem to be passed when I use mina tcp
>> camel endpoint.
>> 
>> Regards
>> 
>> Georgios
>> 
>> 
>> davsclaus wrote:
>>> 
>>> Hi George
>>> 
>>> camel-mina does only support marshalling the body content. (in.body)
>>> What is you use-case for using camel-mina to send messages that contains
>>> headers and properties as well?
>>> 
>>> /Claus
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Camel-TCP-receiver-endpoint-tp15430834s22882p16001744.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Camel TCP receiver endpoint

Posted by davsclaus <ci...@yahoo.dk>.
Gerorge

Have you tried to use your own codec? There is a codec parameter to the uri
configuration of camel routes.

The codec is then your Mina codec class where you can do the encode/decode
where you can include the headers and properties from the exchange.

I am however not sure if using this codec it gives you access to the
exchange in your subclass?

Another approach is to do your own data format, there is some examples in
Camel where you can create your data formatter and annotate them. Then you
can have your dataforma POJO class that holds the body, header and
properties.

You are ofcourse welcome to try to create a patch for camel that includes
the header and properties out-of-the-box. It is however not so easy as the
raw TCP protocol is not a protocol that supports metadata as headers and
properties = everything is one long binary stream. Unlike eg. messaging such
as JMS.


/Claus


georgiosgeorgiadis wrote:
> 
> Hi Claus,
> 
> Yes, the requirement is that we connect to a local or TCP repository with
> the ability to switch from the one or the other only with configuration
> changes. The thing is that we specify some of the stuff in the headers and
> the properties and they don't seem to be passed when I use mina tcp camel
> endpoint.
> 
> Regards
> 
> Georgios
> 
> 
> davsclaus wrote:
>> 
>> Hi George
>> 
>> camel-mina does only support marshalling the body content. (in.body)
>> What is you use-case for using camel-mina to send messages that contains
>> headers and properties as well?
>> 
>> /Claus
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Camel-TCP-receiver-endpoint-tp15430834s22882p15950769.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Camel TCP receiver endpoint

Posted by davsclaus <ci...@yahoo.dk>.
George

CAMEL-383 has been committed to trunk.

Could you try the 1.3-SNAPSHOT to see if it works for you? The
documentations for the new options is in the wiki.
http://activemq.apache.org/camel/mina.html

You can see your unit test in the source code as well
MinaTransferExchangeOptionTest, that demonstrates how to use this new
option.

/Claus
-- 
View this message in context: http://www.nabble.com/Camel-TCP-receiver-endpoint-tp15430834s22882p16247364.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Camel TCP receiver endpoint

Posted by davsclaus <ci...@yahoo.dk>.
George

In you unit test class you must use the sync=true uri parameter to create a
MinaConsumer that uses the InOut pattern.

Your code that creates the producer is correctly set to use InOut pattern.
However since the producer is created with a reference to the same uri
endpoint as the consumer it will inherited the sync=true parameter and thus
auto configure itself to use the InOut pattern.

/Claus
-- 
View this message in context: http://www.nabble.com/Camel-TCP-receiver-endpoint-tp15430834s22882p16067216.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Camel TCP receiver endpoint

Posted by georgiosgeorgiadis <ge...@yahoo.co.uk>.
Hi Claus,

Yes, the requirement is that we connect to a local or TCP repository with
the ability to switch from the one or the other only with configuration
changes. The thing is that we specify some of the stuff in the headers and
the properties and they don't seem to be passed when I use mina tcp camel
endpoint.

Regards

Georgios


davsclaus wrote:
> 
> Hi George
> 
> camel-mina does only support marshalling the body content. (in.body)
> What is you use-case for using camel-mina to send messages that contains
> headers and properties as well?
> 
> /Claus
> 

-- 
View this message in context: http://www.nabble.com/Camel-TCP-receiver-endpoint-tp15430834s22882p15950664.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Camel TCP receiver endpoint

Posted by davsclaus <ci...@yahoo.dk>.
Hi George

camel-mina does only support marshalling the body content. (in.body)
What is you use-case for using camel-mina to send messages that contains
headers and properties as well?

/Claus
-- 
View this message in context: http://www.nabble.com/Camel-TCP-receiver-endpoint-tp15430834s22882p15925676.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Camel TCP receiver endpoint

Posted by georgiosgeorgiadis <ge...@yahoo.co.uk>.
Hi,

Yes, very easy example which I have used before in here:

First I send my Receiver class: 

public class Receiver{ 

  public static void main(String [] s){ 

    try{ 
                
          CamelContext context = new DefaultCamelContext(); 

          context.addRoutes(new RouteBuilder() { 
            public void configure() { 
                from("mina:tcp://localhost:6123").process(new Processor() { 
                    public void process(Exchange e) { 
                    System.out.println("Received exchange: " +
e.getIn().getBody()+"  "+e.getIn().getHeaders()+"   "+e.getProperties()); 
                    } 
                }); 
            } 
        }); 
                
        context.start(); 

    }catch(Throwable ex){ 
      ex.printStackTrace(); 
    } 
  } 
} 

When I start the receiver program, indeed a TCP server at port 6123
startslistening for calls. 

Now my Sender program: 

public class Sender{ 

  public static void main(String [] s){ 

     try{ 

        CamelContext context = new DefaultCamelContext(); 

         context.addRoutes(new RouteBuilder() { 
            public void configure() { 
                from("direct:mycall").process(new Processor() { 
                    public void process(Exchange e) { 
                    System.out.println("Received exchange: " +
e.getIn().getBody()+"  "+e.getIn().getHeaders()+"   "+e.getProperties()); 
                    } 
                }); 
            } 
        }); 

                
        context.start(); 
        
        // CALL DIRECT/BEAN (WORKS(SENDS ALL)
        // Endpoint endpoint = context.getEndpoint("direct:mycall"); 
        // Endpoint endpoint = context.getEndpoint("bean:mybean"); 
        // CALL VIA TCP (NOT SENDING HEADERS/PROPERTIES)
        Endpoint endpoint =
context.getEndpoint("mina:tcp://localhost:6123"); 
        
        MinaExchange exchange =
(MinaExchange)endpoint.createExchange(ExchangePattern.In); 
        
        Message in = exchange.getIn(); 
        
        in.setBody("tcp request"); 

        in.setHeader("headerkey","headervalue");

        exchange.setProperty("prop_key","prop_value");        

        Producer producer = endpoint.createProducer(); 
        
        producer.start(); 
        
        producer.process(exchange); 
        
        Message out = exchange.getOut(); 
        
        System.out.println(out.getBody()); 
        
        producer.stop(); 
        
        context.stop();     

    }catch(Throwable ex){ 
      ex.printStackTrace(); 
    } 

  } 
} 

In the sender you can comment/uncomment the different endpoints and you ill
see the output printed from inside the processor.

Hope that helps.

Thank you

Georgios


davsclaus wrote:
> 
> Georgios,
> 
> Can you provide a small junit test that demonstrates this problem/bug?
> Would be much easier for discussing the problem and providing a patch for
> the bug.
> 
> /Claus
> 
> 
> 
> georgiosgeorgiadis wrote:
>> 
>> I have found out that the message properties and headers soes not seem to
>> be passed when using MINA TCP communication. In direct pojo or bean,
>> everything seems working.
>> 
>> Regards
>> 
>> Georgios
>> 
>> 
>> georgiosgeorgiadis wrote:
>>> 
>>> I am quite new to Camel, but I will need to use camel for implementing
>>> the following requirement:
>>> 
>>> I will need a component to be listening to a specific TCP port. Do I
>>> need to have a custom written TCP server which will serve the TCP
>>> component, or Camel can automatically wrap my component with a Camel TCP
>>> listener (server) using some type of constructor? For example I have the
>>> component:
>>> 
>>> public class MyComponent{
>>>   public void doSomething(){
>>>   }
>>> }
>>> 
>>> possible Camel TCP wrapper
>>> 
>>> Enpoint p  = new CamelTCPEndpoint("localhost",5555,new MyComponent());
>>> p.start();
>>> 
>>> My question is, does something like that exist or do I have to implement
>>> my own custom TCP servers/ listeners for my components? The general
>>> requirement is to have a component which calls a camel sender endpont
>>> which connects synchronously to a camel receiver TCP endpoint which
>>> propages the call to a component and send a reply all the way back to
>>> the sender, basically loosely coupled communication/routing between
>>> different environments.
>>> 
>>> I am trying to reduce communication implementation to the minimum and
>>> just use configurations loaded from a file or repository.
>>> 
>>> Thank you in advance
>>> 
>>> Georgios
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Camel-TCP-receiver-endpoint-tp15430834s22882p15870389.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Camel TCP receiver endpoint

Posted by davsclaus <ci...@yahoo.dk>.
Georgios,

Can you provide a small junit test that demonstrates this problem/bug?
Would be much easier for discussing the problem and providing a patch for
the bug.

/Claus



georgiosgeorgiadis wrote:
> 
> I have found out that the message properties and headers soes not seem to
> be passed when using MINA TCP communication. In direct pojo or bean,
> everything seems working.
> 
> Regards
> 
> Georgios
> 
> 
> georgiosgeorgiadis wrote:
>> 
>> I am quite new to Camel, but I will need to use camel for implementing
>> the following requirement:
>> 
>> I will need a component to be listening to a specific TCP port. Do I need
>> to have a custom written TCP server which will serve the TCP component,
>> or Camel can automatically wrap my component with a Camel TCP listener
>> (server) using some type of constructor? For example I have the
>> component:
>> 
>> public class MyComponent{
>>   public void doSomething(){
>>   }
>> }
>> 
>> possible Camel TCP wrapper
>> 
>> Enpoint p  = new CamelTCPEndpoint("localhost",5555,new MyComponent());
>> p.start();
>> 
>> My question is, does something like that exist or do I have to implement
>> my own custom TCP servers/ listeners for my components? The general
>> requirement is to have a component which calls a camel sender endpont
>> which connects synchronously to a camel receiver TCP endpoint which
>> propages the call to a component and send a reply all the way back to the
>> sender, basically loosely coupled communication/routing between different
>> environments.
>> 
>> I am trying to reduce communication implementation to the minimum and
>> just use configurations loaded from a file or repository.
>> 
>> Thank you in advance
>> 
>> Georgios
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Camel-TCP-receiver-endpoint-tp15430834s22882p15867258.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Camel TCP receiver endpoint

Posted by Taylor Gautier <tg...@terracottatech.com>.


georgiosgeorgiadis wrote:
> 
> I have found out that the message properties and headers soes not seem to
> be passed when using MINA TCP communication. In direct pojo or bean,
> everything seems working.
> 

Georgios,

Is it a hard requirement that your communication happen over a direct TCP
connection?  I just noticed your thread after posting a message about
getting a queue clustered via Terracotta wrapped as a Component.  The effect
is the same - two VMs can easily pass messages using a strategy similar to
seda, except the queue is clustered so the producer can be in one VM and the
consumer in another.

I tested out Headers and Properties to make sure they are passed properly,
and they work fine.

I posted a message with a demo app here:
http://www.nabble.com/Working-Terracotta-Component---Clustered-Queues-in-Camel-td15941549s22882.html

To be sure, this is a much different solution than a raw TCP connection -
Terracotta requires a server and is built for clustering, not raw message
passing from peer to peer - for the moment.  However you do gain some pretty
big benefits - your messages can be seamlessly persistent, changes to the
messages can easily be communicated back to the producer very efficiently
(if you need such a thing) and more.

Anyway...I don't mean to make this a vendor post (I do work for Terracotta
but it's 100% OSS and my implementation is too) - I just thought you might
be interested.
-- 
View this message in context: http://www.nabble.com/Camel-TCP-receiver-endpoint-tp15430834s22882p15943748.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Re: Camel TCP receiver endpoint

Posted by davsclaus <ci...@yahoo.dk>.
Could you raise a JIRA?

Camel MINA for InOut also need exceptionHandling as currently MINA itself
just logs at WARN level.

/Claus


georgiosgeorgiadis wrote:
> 
> I have found out that the message properties and headers soes not seem to
> be passed when using MINA TCP communication. In direct pojo or bean,
> everything seems working.
> 
> Regards
> 
> Georgios
> 
> 
> georgiosgeorgiadis wrote:
>> 
>> I am quite new to Camel, but I will need to use camel for implementing
>> the following requirement:
>> 
>> I will need a component to be listening to a specific TCP port. Do I need
>> to have a custom written TCP server which will serve the TCP component,
>> or Camel can automatically wrap my component with a Camel TCP listener
>> (server) using some type of constructor? For example I have the
>> component:
>> 
>> public class MyComponent{
>>   public void doSomething(){
>>   }
>> }
>> 
>> possible Camel TCP wrapper
>> 
>> Enpoint p  = new CamelTCPEndpoint("localhost",5555,new MyComponent());
>> p.start();
>> 
>> My question is, does something like that exist or do I have to implement
>> my own custom TCP servers/ listeners for my components? The general
>> requirement is to have a component which calls a camel sender endpont
>> which connects synchronously to a camel receiver TCP endpoint which
>> propages the call to a component and send a reply all the way back to the
>> sender, basically loosely coupled communication/routing between different
>> environments.
>> 
>> I am trying to reduce communication implementation to the minimum and
>> just use configurations loaded from a file or repository.
>> 
>> Thank you in advance
>> 
>> Georgios
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Camel-TCP-receiver-endpoint-tp15430834s22882p15830556.html
Sent from the Camel - Users mailing list archive at Nabble.com.