date:20161123

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

2016-11-23 Thread Paolo Patierno

Hi Ganesh,


here it is : https://issues.apache.org/jira/browse/DISPATCH-572


Thanks !

Paolo.


Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor

Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience



From: Ganesh Murthy 
Sent: Wednesday, November 23, 2016 3:11 PM
To: users@qpid.apache.org
Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and 
remote IP/port

Paolo, can you please enter a JIRA for this. Thanks.

- Original Message -
> From: "Paolo Patierno" 
> To: users@qpid.apache.org
> Sent: Wednesday, November 23, 2016 10:00:28 AM
> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and 
> remote IP/port
>
> Exactly Ted ... I got from Ganesh that it's not possible on the "Accepted
> ..." line but it's not necessary.
>
>
> So just a new log line after that when the transport reference is available
> to the router.
>
>
> Paolo Patierno
> Senior Software Engineer (IoT) @ Red Hat
> Microsoft MVP on Windows Embedded & IoT
> Microsoft Azure Advisor
>
> Twitter : @ppatierno
> Linkedin : paolopatierno
> Blog : DevExperience
>
>
> 
> From: Ted Ross 
> Sent: Wednesday, November 23, 2016 2:56 PM
> To: users@qpid.apache.org
> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and
> remote IP/port
>
>
>
> On 11/23/2016 09:14 AM, Ganesh Murthy wrote:
> >
> >
> > - Original Message -
> >> From: "Robbie Gemmell" 
> >> To: users@qpid.apache.org
> >> Sent: Wednesday, November 23, 2016 7:58:48 AM
> >> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier
> >> and remote IP/port
> >>
> >> On 23 November 2016 at 08:04, Paolo Patierno  wrote:
> >>> Hi,
> >>>
> >>>
> >>> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the
> >>> Qpid
> >>> Dispatch Router, I need sometimes to know who is the remote peer is
> >>> exchanging traced messages.
> >>>
> >>>
> >>> For example, considering these few lines of trace (running the Qpid
> >>> Dispatch Router) :
> >>>
> >>>
> >>> Accepted from 127.0.0.1:48192
> >>> Accepted from 127.0.0.1:48190
> >>> [0x7fbc44016390]:  <- SASL
> >>> [0x7fbc44016390]:  -> SASL
> >>> [0x7fbc44003b70]:  <- SASL
> >>> [0x7fbc44003b70]:  -> SASL
> >>> [0x7fbc44016390]:0 -> @sasl-mechanisms(64)
> >>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> >>> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64)
> >>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> >>>
> >>>
> >>> The router accepts two connections from remote clients (we see IP and
> >>> port)
> >>> but then every message is related to an "identifier" (I guess it should
> >>> be
> >>> the file descriptor related to the used socket).
> >>>
> >>
> >> I think the 'identifier' will actually relate to the proton transport,
> >> e.g its address, since the engine doesnt know about the socket.
> >>
> >>> If I need to match these information with Wireshark (where I can see
> >>> remote
> >>> port) I don't know if remote clients using remote port 48192 is related
> >>> to
> >>> 0x7fbc44016390 or 0x7fbc44003b70.
> >>>
> >>>
> >>> I think it could be a good information to add into the trace at least
> >>> showing the "identifier" after the accepted message, i.e. :
> >>>
> >>>
> >>> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> > I don't think we can display the proton transport reference
> > (0x7fbc44016390) next to the host/ephemeral port because we don't have a
> > transport yet. Dispatch router code is accepting the connection in
> > src/driver.c function qdpn_listener_accept() and proton is not in the
> > picture yet.
>
> If we could issue a log once the transport is created that has the
> transport reference and the host/port, that would solve the problem.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: qpid-cpp-1.35 rpm build for SUSE

2016-11-23 Thread rammohan ganapavarapu

Chris,

SLES 12 is working fine, I had issues in SLES 11, can you try on 11?

Ram

On Nov 23, 2016 5:22 AM, "Chris Richardson"  wrote:

> Ram,
>
> I've tried to reproduce your problem with no success. Here are the steps I
> took:
> * Created a new EC2 instance of SLES 12 SP1, ami-cae4b7dd on am3.large
> dual core instance type
> * Installed some prerequisites
>   sudo zypper install cmake
>   sudo zypper install gcc-c++
> * Downloaded and built qpid-proton-0-14 as follows:
>   mkdir -p proton/build
>   cd proton
>   wget http://archive.apache.org/dist/qpid/proton/0.14.0/qpid-
> proton-0.14.0.tar.gz
>   tar zxf qpid-proton-0.14.0.tar.gz
>   cd build/
>   cmake ../qpid-proton-0.14.0
>   make -j3
>
> This built with no problems.
>
> Then I noticed from the pathnames in your original post that you're using
> rpmbuild so I tried that too. I haven't used rpmbuild before but it seems
> you need a specfile, so I hashed one up (see attached). Then I ran
>
> $rpmbuild -ba qpid-proton-0.14.0.spec
>
> and the build succeded again, terminating with the messages:
> Wrote: /home/ec2-user/rpmbuild/SRPMS/qpid-proton-0.14.0-1.src.rpm
> Wrote: /home/ec2-user/rpmbuild/RPMS/x86_64/qpid-proton-0.14.0-1.x86_64.rpm
>
> In both cases the compilation of connection.cpp (which failed in your
> build) happened earlier in my output (27%) than in yours so I guess you're
> including some extra cmake settings you haven't mentioned. This could
> affect the build outcome.
>
> Another possibility common to c++ it that your build system is "dirty" in
> some way, for instance if you have a previous version of proton already
> installed. That could result in the compiler picking up a conflicting
> version of a header file from eg: /usr/include instead of the one it should
> find in your build tree. Might be worth trying this again on a clean system.
>
> Hope that helps!
>
> Chris
>
> On 21 November 2016 at 16:32, rammohan ganapavarapu <
> rammohanga...@gmail.com> wrote:
>
>> Chris,
>>
>> Thanks for trying to help me, below are my env details.
>>
>> OS: SUSE Linux Enterprise Server 12 SP1  (x86_64) - Kernel \r (\l).
>> cmake -version
>> cmake version 2.8.12.1
>> gcc version 4.8.5 (SUSE Linux)
>>
>>
>>
>> Ram
>>
>> On Fri, Nov 18, 2016 at 6:16 PM, Chris Richardson  wrote:
>>
>> > Hi Ram,
>> >
>> > It looks like you're not entirely alone with this problem:
>> > http://stackoverflow.com/questions/39708294/error-changes-meaning-when-
>> > installing-apache-qpid
>> > notably also SUSE, unfortunately no solution posted.
>> >
>> > May I suggest you post some more info about your environment,
>> particularly
>> > arch (whether you're on 32 or 64 bit) and what compiler (incl. version)
>> > you're using. Steps to reproduce would also help. Unfortunately I don't
>> > have SUSE but I'd be happy to test on the distros I do have if it's of
>> any
>> > benefit.
>> >
>> > /Chris
>> >
>> >
>> >
>> > On 18 November 2016 at 23:34, rammohan ganapavarapu <
>> > rammohanga...@gmail.com
>> > > wrote:
>> >
>> > > Hi,
>> > >
>> > > If any one built qpid-cpp rpms for suse please share your experience,
>> if
>> > > you already have a rpms to download please share.
>> > >
>> > > Ram
>> > >
>> > > On Tue, Nov 8, 2016 at 8:19 AM, rammohan ganapavarapu <
>> > > rammohanga...@gmail.com> wrote:
>> > >
>> > > > Hi,
>> > > >
>> > > > I am trying to build qpid-cpp v1.35 rpms for SUSE, while i am
>> building
>> > > > qpid-proton rpm i am getting this compilation error any idea why i
>> am
>> > > > getting this error and how to fix it?
>> > > >
>> > > > [ 34%] Building CXX object proton-c/bindings/cpp/
>> > > > CMakeFiles/qpid-proton-cpp.dir/src/connection.cpp.o
>> > > > In file included from /mnt/ec2-user/rpmbuild/BUILD/
>> > > > qpid-proton-0.14.0/proton-c/bindings/cpp/include/proton/./
>> > > ././link.hpp:31,
>> > > >  from /mnt/ec2-user/rpmbuild/BUILD/
>> > > > qpid-proton-0.14.0/proton-c/bindings/cpp/include/proton/./
>> > > > ./receiver.hpp:27,
>> > > >  from /mnt/ec2-user/rpmbuild/BUILD/
>> > > > qpid-proton-0.14.0/proton-c/bindings/cpp/include/proton/./
>> > > session.hpp:27,
>> > > >  from /mnt/ec2-user/rpmbuild/BUILD/
>> > > > qpid-proton-0.14.0/proton-c/bindings/cpp/include/proton/
>> > > connection.hpp:28,
>> > > >  from /mnt/ec2-user/rpmbuild/BUILD/
>> > > > qpid-proton-0.14.0/proton-c/bindings/cpp/src/connection.cpp:24:
>> > > > /mnt/ec2-user/rpmbuild/BUILD/qpid-proton-0.14.0/proton-c/
>> > > > bindings/cpp/include/proton/././././sender_options.hpp:87: error:
>> > > > declaration of ‘proton::sender_options& proton::sender_options::
>> > > > delivery_mode(proton::delivery_mode)’
>> > > > /mnt/ec2-user/rpmbuild/BUILD/qpid-proton-0.14.0/proton-c/
>> > > > bindings/cpp/include/proton/./././././delivery_mode.hpp:30: error:
>> > > > changes meaning of ‘delivery_mode’ from ‘struct
>> proton::delivery_mode’
>> > > > In file included from /mnt/ec2-user/rpmbuild/BUILD/
>> > > >

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

2016-11-23 Thread Ganesh Murthy

Paolo, can you please enter a JIRA for this. Thanks.

- Original Message -
> From: "Paolo Patierno" 
> To: users@qpid.apache.org
> Sent: Wednesday, November 23, 2016 10:00:28 AM
> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and 
> remote IP/port
> 
> Exactly Ted ... I got from Ganesh that it's not possible on the "Accepted
> ..." line but it's not necessary.
> 
> 
> So just a new log line after that when the transport reference is available
> to the router.
> 
> 
> Paolo Patierno
> Senior Software Engineer (IoT) @ Red Hat
> Microsoft MVP on Windows Embedded & IoT
> Microsoft Azure Advisor
> 
> Twitter : @ppatierno
> Linkedin : paolopatierno
> Blog : DevExperience
> 
> 
> 
> From: Ted Ross 
> Sent: Wednesday, November 23, 2016 2:56 PM
> To: users@qpid.apache.org
> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and
> remote IP/port
> 
> 
> 
> On 11/23/2016 09:14 AM, Ganesh Murthy wrote:
> >
> >
> > - Original Message -
> >> From: "Robbie Gemmell" 
> >> To: users@qpid.apache.org
> >> Sent: Wednesday, November 23, 2016 7:58:48 AM
> >> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier
> >> and remote IP/port
> >>
> >> On 23 November 2016 at 08:04, Paolo Patierno  wrote:
> >>> Hi,
> >>>
> >>>
> >>> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the
> >>> Qpid
> >>> Dispatch Router, I need sometimes to know who is the remote peer is
> >>> exchanging traced messages.
> >>>
> >>>
> >>> For example, considering these few lines of trace (running the Qpid
> >>> Dispatch Router) :
> >>>
> >>>
> >>> Accepted from 127.0.0.1:48192
> >>> Accepted from 127.0.0.1:48190
> >>> [0x7fbc44016390]:  <- SASL
> >>> [0x7fbc44016390]:  -> SASL
> >>> [0x7fbc44003b70]:  <- SASL
> >>> [0x7fbc44003b70]:  -> SASL
> >>> [0x7fbc44016390]:0 -> @sasl-mechanisms(64)
> >>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> >>> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64)
> >>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> >>>
> >>>
> >>> The router accepts two connections from remote clients (we see IP and
> >>> port)
> >>> but then every message is related to an "identifier" (I guess it should
> >>> be
> >>> the file descriptor related to the used socket).
> >>>
> >>
> >> I think the 'identifier' will actually relate to the proton transport,
> >> e.g its address, since the engine doesnt know about the socket.
> >>
> >>> If I need to match these information with Wireshark (where I can see
> >>> remote
> >>> port) I don't know if remote clients using remote port 48192 is related
> >>> to
> >>> 0x7fbc44016390 or 0x7fbc44003b70.
> >>>
> >>>
> >>> I think it could be a good information to add into the trace at least
> >>> showing the "identifier" after the accepted message, i.e. :
> >>>
> >>>
> >>> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> > I don't think we can display the proton transport reference
> > (0x7fbc44016390) next to the host/ephemeral port because we don't have a
> > transport yet. Dispatch router code is accepting the connection in
> > src/driver.c function qdpn_listener_accept() and proton is not in the
> > picture yet.
> 
> If we could issue a log once the transport is created that has the
> transport reference and the host/port, that would solve the problem.
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

2016-11-23 Thread Ted Ross




On 11/23/2016 09:14 AM, Ganesh Murthy wrote:



- Original Message -

From: "Robbie Gemmell" 
To: users@qpid.apache.org
Sent: Wednesday, November 23, 2016 7:58:48 AM
Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and 
remote IP/port

On 23 November 2016 at 08:04, Paolo Patierno  wrote:

Hi,


enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid
Dispatch Router, I need sometimes to know who is the remote peer is
exchanging traced messages.


For example, considering these few lines of trace (running the Qpid
Dispatch Router) :


Accepted from 127.0.0.1:48192
Accepted from 127.0.0.1:48190
[0x7fbc44016390]:  <- SASL
[0x7fbc44016390]:  -> SASL
[0x7fbc44003b70]:  <- SASL
[0x7fbc44003b70]:  -> SASL
[0x7fbc44016390]:0 -> @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
[0x7fbc44003b70]:0 -> @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]


The router accepts two connections from remote clients (we see IP and port)
but then every message is related to an "identifier" (I guess it should be
the file descriptor related to the used socket).



I think the 'identifier' will actually relate to the proton transport,
e.g its address, since the engine doesnt know about the socket.


If I need to match these information with Wireshark (where I can see remote
port) I don't know if remote clients using remote port 48192 is related to
0x7fbc44016390 or 0x7fbc44003b70.


I think it could be a good information to add into the trace at least
showing the "identifier" after the accepted message, i.e. :


Accepted from 127.0.0.1:48192 [0x7fbc44016390]

I don't think we can display the proton transport reference (0x7fbc44016390) 
next to the host/ephemeral port because we don't have a transport yet. Dispatch 
router code is accepting the connection in src/driver.c function 
qdpn_listener_accept() and proton is not in the picture yet.


If we could issue a log once the transport is created that has the 
transport reference and the host/port, that would solve the problem.



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

2016-11-23 Thread Paolo Patierno

Exactly Ted ... I got from Ganesh that it's not possible on the "Accepted ..." 
line but it's not necessary.


So just a new log line after that when the transport reference is available to 
the router.


Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor

Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience



From: Ted Ross 
Sent: Wednesday, November 23, 2016 2:56 PM
To: users@qpid.apache.org
Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and 
remote IP/port



On 11/23/2016 09:14 AM, Ganesh Murthy wrote:
>
>
> - Original Message -
>> From: "Robbie Gemmell" 
>> To: users@qpid.apache.org
>> Sent: Wednesday, November 23, 2016 7:58:48 AM
>> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and 
>> remote IP/port
>>
>> On 23 November 2016 at 08:04, Paolo Patierno  wrote:
>>> Hi,
>>>
>>>
>>> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid
>>> Dispatch Router, I need sometimes to know who is the remote peer is
>>> exchanging traced messages.
>>>
>>>
>>> For example, considering these few lines of trace (running the Qpid
>>> Dispatch Router) :
>>>
>>>
>>> Accepted from 127.0.0.1:48192
>>> Accepted from 127.0.0.1:48190
>>> [0x7fbc44016390]:  <- SASL
>>> [0x7fbc44016390]:  -> SASL
>>> [0x7fbc44003b70]:  <- SASL
>>> [0x7fbc44003b70]:  -> SASL
>>> [0x7fbc44016390]:0 -> @sasl-mechanisms(64)
>>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>>> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64)
>>> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>>>
>>>
>>> The router accepts two connections from remote clients (we see IP and port)
>>> but then every message is related to an "identifier" (I guess it should be
>>> the file descriptor related to the used socket).
>>>
>>
>> I think the 'identifier' will actually relate to the proton transport,
>> e.g its address, since the engine doesnt know about the socket.
>>
>>> If I need to match these information with Wireshark (where I can see remote
>>> port) I don't know if remote clients using remote port 48192 is related to
>>> 0x7fbc44016390 or 0x7fbc44003b70.
>>>
>>>
>>> I think it could be a good information to add into the trace at least
>>> showing the "identifier" after the accepted message, i.e. :
>>>
>>>
>>> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
> I don't think we can display the proton transport reference (0x7fbc44016390) 
> next to the host/ephemeral port because we don't have a transport yet. 
> Dispatch router code is accepting the connection in src/driver.c function 
> qdpn_listener_accept() and proton is not in the picture yet.

If we could issue a log once the transport is created that has the
transport reference and the host/port, that would solve the problem.


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

2016-11-23 Thread Paolo Patierno

Hi Ganesh,


after the connection is accepted there is no other way to print the proton 
transport reference for the couple IP/port ? In order to have just one line of 
trace for it (even if we can't write it near the "Accepted ..." message).


If not, I agree that the trace could be big printing the IP/port for every 
line; could be it conditional ? (i.e. using an env variable for tracing)


I'm just saying that in order to have a correlation between what I see from the 
proton trace and Wireshark.


Thanks,

Paolo.



Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor

Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience



From: Ganesh Murthy 
Sent: Wednesday, November 23, 2016 2:14 PM
To: users@qpid.apache.org
Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and 
remote IP/port



- Original Message -
> From: "Robbie Gemmell" 
> To: users@qpid.apache.org
> Sent: Wednesday, November 23, 2016 7:58:48 AM
> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and 
> remote IP/port
>
> On 23 November 2016 at 08:04, Paolo Patierno  wrote:
> > Hi,
> >
> >
> > enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid
> > Dispatch Router, I need sometimes to know who is the remote peer is
> > exchanging traced messages.
> >
> >
> > For example, considering these few lines of trace (running the Qpid
> > Dispatch Router) :
> >
> >
> > Accepted from 127.0.0.1:48192
> > Accepted from 127.0.0.1:48190
> > [0x7fbc44016390]:  <- SASL
> > [0x7fbc44016390]:  -> SASL
> > [0x7fbc44003b70]:  <- SASL
> > [0x7fbc44003b70]:  -> SASL
> > [0x7fbc44016390]:0 -> @sasl-mechanisms(64)
> > [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> > [0x7fbc44003b70]:0 -> @sasl-mechanisms(64)
> > [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> >
> >
> > The router accepts two connections from remote clients (we see IP and port)
> > but then every message is related to an "identifier" (I guess it should be
> > the file descriptor related to the used socket).
> >
>
> I think the 'identifier' will actually relate to the proton transport,
> e.g its address, since the engine doesnt know about the socket.
>
> > If I need to match these information with Wireshark (where I can see remote
> > port) I don't know if remote clients using remote port 48192 is related to
> > 0x7fbc44016390 or 0x7fbc44003b70.
> >
> >
> > I think it could be a good information to add into the trace at least
> > showing the "identifier" after the accepted message, i.e. :
> >
> >
> > Accepted from 127.0.0.1:48192 [0x7fbc44016390]
I don't think we can display the proton transport reference (0x7fbc44016390) 
next to the host/ephemeral port because we don't have a transport yet. Dispatch 
router code is accepting the connection in src/driver.c function 
qdpn_listener_accept() and proton is not in the picture yet.
> >
> >
> > It's also true, that messages related to something like [0x7fbc44016390]
> > come from Qpid Proton and messages like "Accepted ..." come from Qpid
> > Dispatch Router.
> >
>
> Yep, by setting PN_TRACE_FRM it is Proton doing that logging, and it
> doesnt know about the host/port/socket and is just dealing with bytes
> in/out.
>
> That said, I beleive you can set a 'tracer' used to output the
> message, e.g to your own log stream, which could also allow augmenting
> it with more information.

Yes, Dispatch does set a tracer by calling proton's pn_transport_set_tracer 
function and passing it a callback function like this in src/server.c

pn_transport_set_tracer(tport, qd_transport_tracer);

static void qd_transport_tracer(pn_transport_t *transport, const char *message)
{
qd_connection_t *ctx = (qd_connection_t*) 
pn_transport_get_context(transport);
if (ctx)
qd_log(ctx->server->log_source, QD_LOG_TRACE, "[%"PRIu64"]:%s", 
ctx->connection_id, message);
}

As you can see above, Dispatch has access to qd_connection_t *ctx and it is 
adding its own connection_id to the proton message. We could potentially 
display the host and the port on every trace message but that would lead to 
large trace messages particularly in cases where the hostname is long.

Thanks.
>
> >
> > Thanks,
> >
> > Paolo.
> >
> >
> >
> > Paolo Patierno
> > Senior Software Engineer (IoT) @ Red Hat
> > Microsoft MVP on Windows Embedded & IoT
> > Microsoft Azure Advisor
> >
> > Twitter : @ppatierno
> > Linkedin : paolopatierno
> > Blog : DevExperience
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

2016-11-23 Thread Ganesh Murthy



- Original Message -
> From: "Robbie Gemmell" 
> To: users@qpid.apache.org
> Sent: Wednesday, November 23, 2016 7:58:48 AM
> Subject: Re: Qpid Proton/Dispath trace : correlate connection identifier and 
> remote IP/port
> 
> On 23 November 2016 at 08:04, Paolo Patierno  wrote:
> > Hi,
> >
> >
> > enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid
> > Dispatch Router, I need sometimes to know who is the remote peer is
> > exchanging traced messages.
> >
> >
> > For example, considering these few lines of trace (running the Qpid
> > Dispatch Router) :
> >
> >
> > Accepted from 127.0.0.1:48192
> > Accepted from 127.0.0.1:48190
> > [0x7fbc44016390]:  <- SASL
> > [0x7fbc44016390]:  -> SASL
> > [0x7fbc44003b70]:  <- SASL
> > [0x7fbc44003b70]:  -> SASL
> > [0x7fbc44016390]:0 -> @sasl-mechanisms(64)
> > [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> > [0x7fbc44003b70]:0 -> @sasl-mechanisms(64)
> > [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> >
> >
> > The router accepts two connections from remote clients (we see IP and port)
> > but then every message is related to an "identifier" (I guess it should be
> > the file descriptor related to the used socket).
> >
> 
> I think the 'identifier' will actually relate to the proton transport,
> e.g its address, since the engine doesnt know about the socket.
> 
> > If I need to match these information with Wireshark (where I can see remote
> > port) I don't know if remote clients using remote port 48192 is related to
> > 0x7fbc44016390 or 0x7fbc44003b70.
> >
> >
> > I think it could be a good information to add into the trace at least
> > showing the "identifier" after the accepted message, i.e. :
> >
> >
> > Accepted from 127.0.0.1:48192 [0x7fbc44016390]
I don't think we can display the proton transport reference (0x7fbc44016390) 
next to the host/ephemeral port because we don't have a transport yet. Dispatch 
router code is accepting the connection in src/driver.c function 
qdpn_listener_accept() and proton is not in the picture yet.
> >
> >
> > It's also true, that messages related to something like [0x7fbc44016390]
> > come from Qpid Proton and messages like "Accepted ..." come from Qpid
> > Dispatch Router.
> >
> 
> Yep, by setting PN_TRACE_FRM it is Proton doing that logging, and it
> doesnt know about the host/port/socket and is just dealing with bytes
> in/out.
> 
> That said, I beleive you can set a 'tracer' used to output the
> message, e.g to your own log stream, which could also allow augmenting
> it with more information.

Yes, Dispatch does set a tracer by calling proton's pn_transport_set_tracer 
function and passing it a callback function like this in src/server.c

pn_transport_set_tracer(tport, qd_transport_tracer);

static void qd_transport_tracer(pn_transport_t *transport, const char *message)
{
qd_connection_t *ctx = (qd_connection_t*) 
pn_transport_get_context(transport);
if (ctx)
qd_log(ctx->server->log_source, QD_LOG_TRACE, "[%"PRIu64"]:%s", 
ctx->connection_id, message);
}

As you can see above, Dispatch has access to qd_connection_t *ctx and it is 
adding its own connection_id to the proton message. We could potentially 
display the host and the port on every trace message but that would lead to 
large trace messages particularly in cases where the hostname is long.

Thanks.
> 
> >
> > Thanks,
> >
> > Paolo.
> >
> >
> >
> > Paolo Patierno
> > Senior Software Engineer (IoT) @ Red Hat
> > Microsoft MVP on Windows Embedded & IoT
> > Microsoft Azure Advisor
> >
> > Twitter : @ppatierno
> > Linkedin : paolopatierno
> > Blog : DevExperience
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: qpid-cpp-1.35 rpm build for SUSE

2016-11-23 Thread Chris Richardson

Ram,

I've tried to reproduce your problem with no success. Here are the steps I
took:
* Created a new EC2 instance of SLES 12 SP1, ami-cae4b7dd on am3.large dual
core instance type
* Installed some prerequisites
  sudo zypper install cmake
  sudo zypper install gcc-c++
* Downloaded and built qpid-proton-0-14 as follows:
  mkdir -p proton/build
  cd proton
  wget
http://archive.apache.org/dist/qpid/proton/0.14.0/qpid-proton-0.14.0.tar.gz
  tar zxf qpid-proton-0.14.0.tar.gz
  cd build/
  cmake ../qpid-proton-0.14.0
  make -j3

This built with no problems.

Then I noticed from the pathnames in your original post that you're using
rpmbuild so I tried that too. I haven't used rpmbuild before but it seems
you need a specfile, so I hashed one up (see attached). Then I ran

$rpmbuild -ba qpid-proton-0.14.0.spec

and the build succeded again, terminating with the messages:
Wrote: /home/ec2-user/rpmbuild/SRPMS/qpid-proton-0.14.0-1.src.rpm
Wrote: /home/ec2-user/rpmbuild/RPMS/x86_64/qpid-proton-0.14.0-1.x86_64.rpm

In both cases the compilation of connection.cpp (which failed in your
build) happened earlier in my output (27%) than in yours so I guess you're
including some extra cmake settings you haven't mentioned. This could
affect the build outcome.

Another possibility common to c++ it that your build system is "dirty" in
some way, for instance if you have a previous version of proton already
installed. That could result in the compiler picking up a conflicting
version of a header file from eg: /usr/include instead of the one it should
find in your build tree. Might be worth trying this again on a clean system.

Hope that helps!

Chris

On 21 November 2016 at 16:32, rammohan ganapavarapu  wrote:

> Chris,
>
> Thanks for trying to help me, below are my env details.
>
> OS: SUSE Linux Enterprise Server 12 SP1  (x86_64) - Kernel \r (\l).
> cmake -version
> cmake version 2.8.12.1
> gcc version 4.8.5 (SUSE Linux)
>
>
>
> Ram
>
> On Fri, Nov 18, 2016 at 6:16 PM, Chris Richardson  wrote:
>
> > Hi Ram,
> >
> > It looks like you're not entirely alone with this problem:
> > http://stackoverflow.com/questions/39708294/error-changes-meaning-when-
> > installing-apache-qpid
> > notably also SUSE, unfortunately no solution posted.
> >
> > May I suggest you post some more info about your environment,
> particularly
> > arch (whether you're on 32 or 64 bit) and what compiler (incl. version)
> > you're using. Steps to reproduce would also help. Unfortunately I don't
> > have SUSE but I'd be happy to test on the distros I do have if it's of
> any
> > benefit.
> >
> > /Chris
> >
> >
> >
> > On 18 November 2016 at 23:34, rammohan ganapavarapu <
> > rammohanga...@gmail.com
> > > wrote:
> >
> > > Hi,
> > >
> > > If any one built qpid-cpp rpms for suse please share your experience,
> if
> > > you already have a rpms to download please share.
> > >
> > > Ram
> > >
> > > On Tue, Nov 8, 2016 at 8:19 AM, rammohan ganapavarapu <
> > > rammohanga...@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > I am trying to build qpid-cpp v1.35 rpms for SUSE, while i am
> building
> > > > qpid-proton rpm i am getting this compilation error any idea why i am
> > > > getting this error and how to fix it?
> > > >
> > > > [ 34%] Building CXX object proton-c/bindings/cpp/
> > > > CMakeFiles/qpid-proton-cpp.dir/src/connection.cpp.o
> > > > In file included from /mnt/ec2-user/rpmbuild/BUILD/
> > > > qpid-proton-0.14.0/proton-c/bindings/cpp/include/proton/./
> > > ././link.hpp:31,
> > > >  from /mnt/ec2-user/rpmbuild/BUILD/
> > > > qpid-proton-0.14.0/proton-c/bindings/cpp/include/proton/./
> > > > ./receiver.hpp:27,
> > > >  from /mnt/ec2-user/rpmbuild/BUILD/
> > > > qpid-proton-0.14.0/proton-c/bindings/cpp/include/proton/./
> > > session.hpp:27,
> > > >  from /mnt/ec2-user/rpmbuild/BUILD/
> > > > qpid-proton-0.14.0/proton-c/bindings/cpp/include/proton/
> > > connection.hpp:28,
> > > >  from /mnt/ec2-user/rpmbuild/BUILD/
> > > > qpid-proton-0.14.0/proton-c/bindings/cpp/src/connection.cpp:24:
> > > > /mnt/ec2-user/rpmbuild/BUILD/qpid-proton-0.14.0/proton-c/
> > > > bindings/cpp/include/proton/././././sender_options.hpp:87: error:
> > > > declaration of ‘proton::sender_options& proton::sender_options::
> > > > delivery_mode(proton::delivery_mode)’
> > > > /mnt/ec2-user/rpmbuild/BUILD/qpid-proton-0.14.0/proton-c/
> > > > bindings/cpp/include/proton/./././././delivery_mode.hpp:30: error:
> > > > changes meaning of ‘delivery_mode’ from ‘struct
> proton::delivery_mode’
> > > > In file included from /mnt/ec2-user/rpmbuild/BUILD/
> > > > qpid-proton-0.14.0/proton-c/bindings/cpp/include/proton/./
> > > ././link.hpp:32,
> > > >  from /mnt/ec2-user/rpmbuild/BUILD/
> > > > qpid-proton-0.14.0/proton-c/bindings/cpp/include/proton/./
> > > > ./receiver.hpp:27,
> > > >  from /mnt/ec2-user/rpmbuild/BUILD/
> > > >

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

2016-11-23 Thread Robbie Gemmell

On 23 November 2016 at 08:04, Paolo Patierno  wrote:
> Hi,
>
>
> enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid 
> Dispatch Router, I need sometimes to know who is the remote peer is 
> exchanging traced messages.
>
>
> For example, considering these few lines of trace (running the Qpid Dispatch 
> Router) :
>
>
> Accepted from 127.0.0.1:48192
> Accepted from 127.0.0.1:48190
> [0x7fbc44016390]:  <- SASL
> [0x7fbc44016390]:  -> SASL
> [0x7fbc44003b70]:  <- SASL
> [0x7fbc44003b70]:  -> SASL
> [0x7fbc44016390]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> [0x7fbc44003b70]:0 -> @sasl-mechanisms(64) 
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
>
>
> The router accepts two connections from remote clients (we see IP and port) 
> but then every message is related to an "identifier" (I guess it should be 
> the file descriptor related to the used socket).
>

I think the 'identifier' will actually relate to the proton transport,
e.g its address, since the engine doesnt know about the socket.

> If I need to match these information with Wireshark (where I can see remote 
> port) I don't know if remote clients using remote port 48192 is related to 
> 0x7fbc44016390 or 0x7fbc44003b70.
>
>
> I think it could be a good information to add into the trace at least showing 
> the "identifier" after the accepted message, i.e. :
>
>
> Accepted from 127.0.0.1:48192 [0x7fbc44016390]
>
>
> It's also true, that messages related to something like [0x7fbc44016390] come 
> from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch 
> Router.
>

Yep, by setting PN_TRACE_FRM it is Proton doing that logging, and it
doesnt know about the host/port/socket and is just dealing with bytes
in/out.

That said, I beleive you can set a 'tracer' used to output the
message, e.g to your own log stream, which could also allow augmenting
it with more information.

>
> Thanks,
>
> Paolo.
>
>
>
> Paolo Patierno
> Senior Software Engineer (IoT) @ Red Hat
> Microsoft MVP on Windows Embedded & IoT
> Microsoft Azure Advisor
>
> Twitter : @ppatierno
> Linkedin : paolopatierno
> Blog : DevExperience

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

[NOTICE/DISCUSS] Making proton-j and proton-c more independent

2016-11-23 Thread Robbie Gemmell

I'd like to call this out more specifically following discussion in a
couple of recent threads, to ensure folks are clear on things before
they proceed. If not, shout.

Following completion of the 0.16.0 release, I will look to proceed
with making proton-j and proton-c (+bindings) more independent to
allow them to each be released individually and more easily differ
where appropriate in order to best serve users needs. As part of this
I will look to:

- Have infra create a separate repository for proton-j, likely "qpid-proton-j".
- Remove Messenger from proton-j.

On the former, I think just cloning the existing repo and trimming
things to leave the bits of interest is probably the easiest way to
go, with a reverse trim happening for the existing repository. Any
other thoughts on that?

On the latter, I still need to look at the overall impact, since some
of the python tests do use Messenger and I believe not always to test
Messenger-specific things. If there are tests using messenger that are
of obvious interest which can't quickly be replaced, then I would move
the messenger impl to just being part of the tests to at the very
least remove it from the main component until they can be replaced.
I'd look to keep as many of the non-messenger tests as we can
initially, replacing them over time where appropriate.

We should start by marking proton-j messenger as deprecated in 0.16.0,
I will do that shortly. The rest will begin after 0.16.0 is complete.

Robbie

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

2016-11-23 Thread Adel Boutros

+1


Regards,

Adel


From: Paolo Patierno 
Sent: Wednesday, November 23, 2016 9:04:36 AM
To: users@qpid.apache.org
Subject: Qpid Proton/Dispath trace : correlate connection identifier and remote 
IP/port

Hi,


enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid 
Dispatch Router, I need sometimes to know who is the remote peer is exchanging 
traced messages.


For example, considering these few lines of trace (running the Qpid Dispatch 
Router) :


Accepted from 127.0.0.1:48192
Accepted from 127.0.0.1:48190
[0x7fbc44016390]:  <- SASL
[0x7fbc44016390]:  -> SASL
[0x7fbc44003b70]:  <- SASL
[0x7fbc44003b70]:  -> SASL
[0x7fbc44016390]:0 -> @sasl-mechanisms(64) 
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
[0x7fbc44003b70]:0 -> @sasl-mechanisms(64) 
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]


The router accepts two connections from remote clients (we see IP and port) but 
then every message is related to an "identifier" (I guess it should be the file 
descriptor related to the used socket).

If I need to match these information with Wireshark (where I can see remote 
port) I don't know if remote clients using remote port 48192 is related to 
0x7fbc44016390 or 0x7fbc44003b70.


I think it could be a good information to add into the trace at least showing 
the "identifier" after the accepted message, i.e. :


Accepted from 127.0.0.1:48192 [0x7fbc44016390]


It's also true, that messages related to something like [0x7fbc44016390] come 
from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch 
Router.


Thanks,

Paolo.



Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor

Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience

Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

2016-11-23 Thread Paolo Patierno

Hi,


enabling the Qpid Proton trace through PN_TRACE_FRM=1 when I start the Qpid 
Dispatch Router, I need sometimes to know who is the remote peer is exchanging 
traced messages.


For example, considering these few lines of trace (running the Qpid Dispatch 
Router) :


Accepted from 127.0.0.1:48192
Accepted from 127.0.0.1:48190
[0x7fbc44016390]:  <- SASL
[0x7fbc44016390]:  -> SASL
[0x7fbc44003b70]:  <- SASL
[0x7fbc44003b70]:  -> SASL
[0x7fbc44016390]:0 -> @sasl-mechanisms(64) 
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
[0x7fbc44003b70]:0 -> @sasl-mechanisms(64) 
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]


The router accepts two connections from remote clients (we see IP and port) but 
then every message is related to an "identifier" (I guess it should be the file 
descriptor related to the used socket).

If I need to match these information with Wireshark (where I can see remote 
port) I don't know if remote clients using remote port 48192 is related to 
0x7fbc44016390 or 0x7fbc44003b70.


I think it could be a good information to add into the trace at least showing 
the "identifier" after the accepted message, i.e. :


Accepted from 127.0.0.1:48192 [0x7fbc44016390]


It's also true, that messages related to something like [0x7fbc44016390] come 
from Qpid Proton and messages like "Accepted ..." come from Qpid Dispatch 
Router.


Thanks,

Paolo.



Paolo Patierno
Senior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoT
Microsoft Azure Advisor

Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Re: qpid-cpp-1.35 rpm build for SUSE

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Re: qpid-cpp-1.35 rpm build for SUSE

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

[NOTICE/DISCUSS] Making proton-j and proton-c more independent

Re: Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

Qpid Proton/Dispath trace : correlate connection identifier and remote IP/port

12 matches

Site Navigation

Mail list logo

Footer information