Re: [VOTE] merge the proton mailing list into the users/dev lists

[Jakub Scholz]

+1

On Wed, Mar 30, 2016 at 1:01 PM, Kai  wrote:

> +1
>
> On Wed, Mar 30, 2016 at 12:25 PM Robbie Gemmell  wrote:
>
> > Hello folks,
> >
> > Many moons ago, a seperate mailing list was established for Proton,
> > back when it was purely a protocol engine other components would use.
> > Its scope has since expanded beyond that and the separate mailing list
> > has I feel been an increasing source of confusion and hassle of late
> > more than anything else. Collapsing it into the other larger existing
> > lists we have (that the traffic would otherwise have been on) seems to
> > me like it would be an improvement across the board, and as such I
> > have called this vote.
> >
> > I would propose that discussion (such as this) would head to the
> > users@q.a.o list to join the similar/related/duplicate traffic already
> > present, with remaining things going to the dev@q.a.o list as
> > consistent with that list (e.g JIRA, GitHub integration mails,
> > ReviewBoard, though the latter was never actually directed to proton@
> > to begin with..).
> >
> > Whilst redirecting JIRA etc emails should be easy enough (has been
> > done before), I dont know what the precise options are regarding
> > existing mail subscriptions to the list. There are significantly more
> > subscribers to users@ than proton@, and many are duplicates, but some
> > are not. I'd need to discuss options with infra, but first things
> > first, the vote.
> >
> > I have gone straight to a vote on this because I feel this has already
> > been discussed enough previously over time that many people will have
> > already thought about it enough to quickly vote one way or the other,
> > and it is past time to act on it if things head that way. Obviously
> > things can be further discusssed at this point also if desired.
> >
> > Note that both users@ and proton@ are in the recipients. I expect the
> > thread will splinter when someone forgets to reply-all, as almost all
> > cross-posted thread on the lists do, but at least it can start on both
> > for visibility to all.
> >
> > Robbie
> >
>

Re: Need Help! qpid-cofig: No module named qpid.messaging

[Jakub Scholz]

I think you need to download and install the Python version of the Qpid
Messaging API. You can download it for example here
http://qpid.apache.org/components/messaging-api/index.html or on
http://qpid.apache.org/download.html. If you don't want to install it into
the system directories, it should be enough if you copy the mllib and qpid
directories next to your qpid-config.

On Mon, Feb 22, 2016 at 4:40 PM, Flores, Paul A. 
wrote:

> Help!
>
>
>
> All the I can find when I Google on this messaging I am getting is dated
> 2010.  It references a QMF extras folder that does not exist.
>
>
>
> Surely there has to be some updated guidance to this issue?
>
>
>
> This is "blocking" my current sprint progress!
>

Re: Help?!: Qpid JMS 0.6.0 HelloWorld example issue

[Jakub Scholz]

qpid-config is in the qpid-tools package. Go to the download site (
http://qpid.apache.org/download.html) and download the "C++ broker
(command-line tools)". It is using the Python version of Qpid Messaging
API, so you have to download that as well - it is on the same page.

On Fri, Feb 19, 2016 at 10:28 PM, Flores, Paul A. 
wrote:

> I got that far now I am trying to create a queue.  Don't seem to able to
> find qpid-config.  In what release/download is that found?
>
> 
> From: Timothy Bish [tabish...@gmail.com]
> Sent: Friday, February 19, 2016 2:41 PM
> To: proton@qpid.apache.org
> Subject: Re: Help?!: Qpid JMS 0.6.0 HelloWorld example issue
>
> On 02/19/2016 12:39 PM, Flores, Paul A. wrote:
> > Trying to get the HelloWorld example that is found with the QPID JMS
> 0.6.0 Release to work.
> >
> >
> >
> > When I go to run it  I am seeing the following.
> >
> >
> >
> > Can some one point me to a resolution? I am running out of hair to pull!
> >
>
> Try changing you URI in the jndi.properties to 'amqp://localhost:5672'
> not the 'amqp' is not capitalized.
>
> >
> > Thanks.
> >
> >
> >
> > Paul
> >
> >
> >
> > 2016-02-19 10:32:47,256 [main   ] - ERROR ProviderFactory
> - Failed to create Provider instance for AMQP, due to:
> java.io.IOException: Provider scheme NOT recognized: [AMQP]
> > 2016-02-19 10:32:47,259 [main   ] - ERROR JmsConnectionFactory
>  - Failed to create JMS Provider instance for: AMQP
> > Caught exception, exiting.
> > javax.jms.JMSException: Failed to create connection to:
> AMQP://localhost:5672
> > at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:66)
> > at
> org.apache.qpid.jms.JmsConnectionFactory.createConnection(JmsConnectionFactory.java:165)
> > at HelloWorld.main(HelloWorld.java:51)
> > Caused by: java.io.IOException: Provider scheme NOT recognized: [AMQP]
> > at
> org.apache.qpid.jms.provider.ProviderFactory.findProviderFactory(ProviderFactory.java:104)
> > at
> org.apache.qpid.jms.provider.ProviderFactory.create(ProviderFactory.java:70)
> > at
> org.apache.qpid.jms.JmsConnectionFactory.createProvider(JmsConnectionFactory.java:221)
> > at
> org.apache.qpid.jms.JmsConnectionFactory.createConnection(JmsConnectionFactory.java:161)
> > ... 1 more
> > Caused by: org.apache.qpid.jms.util.ResourceNotFoundException: Could not
> find factory resource: META-INF/services/org/apache/qpid/jms/provider/AMQP
> > at
> org.apache.qpid.jms.util.FactoryFinder$StandaloneObjectFactory.loadProperties(FactoryFinder.java:223)
> > at
> org.apache.qpid.jms.util.FactoryFinder$StandaloneObjectFactory.create(FactoryFinder.java:164)
> > at
> org.apache.qpid.jms.util.FactoryFinder.newInstance(FactoryFinder.java:122)
> > at
> org.apache.qpid.jms.provider.ProviderFactory.findProviderFactory(ProviderFactory.java:102)
> > ... 4 more
> >
>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/

[jira] [Created] (PROTON-1139) tx_recv_interactive.py example doesn't work

[Jakub Scholz (JIRA)]

Jakub Scholz created PROTON-1139:


 Summary: tx_recv_interactive.py example doesn't work
 Key: PROTON-1139
 URL: https://issues.apache.org/jira/browse/PROTON-1139
 Project: Qpid Proton
  Issue Type: Bug
  Components: python-binding
Affects Versions: 0.12.0
Reporter: Jakub Scholz
Priority: Minor


It looks like the tx_recv_interactive.py example doesn't work anymore, because 
the get_event_trigger method no longer exists.

$ ./tx_recv_interactive.py
Traceback (most recent call last):
  File "./tx_recv_interactive.py", line 70, in 
events = reactor.get_event_trigger()
  File "/usr/lib64/python2.7/site-packages/proton/wrapper.py", line 69, in 
__getattr__
raise AttributeError(name + " not in _attrs")
AttributeError: get_event_trigger not in _attrs

It looks like it should be replaced by the selectable method and EventInjector 
object.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release RC 3 as Qpid Proton 0.12.0

[Jakub Scholz]

+1

* I checked the JMS client with 0.12.0-rc3 against MRG-M 3.0 & 3.2 and
against Qpid C++ broker (trunk with 0.12.0-rc3)
* I checked the Qpid Messaging C++ client build with 0.12.0-rc3 against
MRG-M 3.0 and 3.2

On Wed, Feb 10, 2016 at 3:04 PM, Justin Ross  wrote:

> Hi, everyone.  RC 2 had some embedded build output, which this RC removes.
> Apart from that removal, it has the same content as RC 2.
>
> The proposed release artifacts:
>
> https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc3/
>
> Please indicate your vote below.  If you favor releasing the 0.12.0 RC 3
> bits as 0.12.0 GA, vote +1.  If you have reason to think RC 3 is not
> ready for release, vote -1.
>
> Thanks,
> Justin
>

Re: [VOTE] Release Qpid Proton 0.12.0

[Jakub Scholz]

+1

- I checked the JMS client with 0.12.0-rc against MRG-M 3.2 and against
Qpid C++ broker (trunk with 0.12.0-rc)
- I checked the Qpid Messaging C++ client build with 0.12.0-rc against
MRG-M 3.0

On Wed, Feb 3, 2016 at 4:10 PM, Justin Ross  wrote:

> The artifacts proposed for release:
>
> https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-rc/
>
> Please indicate your vote below.  If you favor releasing the 0.12.0 RC bits
> as 0.12.0 GA, vote +1.  If you have reason to think the RC is not ready for
> release, vote -1.
>
> Thanks,
> Justin
>

Re: Proposed SASL changes (API and functional)

[Jakub Scholz]

On Wed, Feb 25, 2015 at 7:45 PM, Andrew Stitcher astitc...@redhat.com
wrote:

 If it is ok with them I will copy the comments over there:
 Alan, Jakub?


Sorry, I missed the wiki part. Feel free to copy my comment there if you
want.

Re: Proposed SASL changes (API and functional)

[Jakub Scholz]

Hi Andrew,

I'm definitely not a Proton expert, so please excuse me if I missed
something.

But I find this part a bit dangerous:
Classically in protocols where SASL was not optional the way to avoid
double authentication was to use the EXTERNAL SASL mechanism. With AMQP,
SASL is optional, so if SSL is used for client authentication the SASL
layer could be entirely omitted and so using EXTERNAL is not necessary.

I understand the idea and I would even agree that this is the proper way
how to do it in the long term. But I'm not sure whether all brokers support
this concept. For example, I'm not sure whether you can configure the Qpid
C++ broker in a way to accept AMQP 1.0 connections with SSL Client
Authentication without SASL EXTERNAL while at the same time accepting AMQP
0-10 connections only with SASL EXTERNAL. Therefore I would be afraid that
allowing SSL Client Authentication only without SASL could cause some
serious incompatibilities - I think both should be possible / supported.

Regards
Jakub

On Tue, Feb 24, 2015 at 9:48 PM, Andrew Stitcher astitc...@redhat.com
wrote:

 As many of you know I've been working on implementing a SASL AMQP
 protocol layer that does more than PLAIN and ANONYMOUS for proton-c.

 I'm currently in at a point where the work is reasonably functional
 (with some gaps)

 I've put together a fairly comprehensive account of this work on the
 Apache wiki: https://cwiki.apache.org/confluence/x/B5cWAw

 If you are at all interested please go and look at the proposal and
 comment on it there.

 You can see my actual code changes in my github proton repo:
 https://github.com/astitcher/qpid-proton/commits/sasl-work

 [This is my working branch, so not all the changes make a lot of sense,
 just pay attention to the tip of the branch]

 In a short while when people have had enough time to absorb the proposal
 and comment I will post a code review of the actual code changes. As
 there are substantial API changes I'd like to get this in for 0.9
 because we were intending to stabilise the API at this point.

 Thanks.

 Andrew

[jira] [Created] (PROTON-363) recv.exe fails on Windows XP because getnameinfo returns WSANO_DATA / error 11004

[JAkub Scholz (JIRA)]

JAkub Scholz created PROTON-363:
---

 Summary: recv.exe fails on Windows XP because getnameinfo returns 
WSANO_DATA / error 11004
 Key: PROTON-363
 URL: https://issues.apache.org/jira/browse/PROTON-363
 Project: Qpid Proton
  Issue Type: Bug
  Components: proton-c
Affects Versions: 0.5
 Environment: Windows XP, Visual Studio 2010
Reporter: JAkub Scholz


I build the proton-c library on Windows XP using Visual Studio 10. Afterwards, 
when trying to run the recv.exe and send.exe examples, the recv.exe always 
fails with:

 recv.exe amqp://~0.0.0.0:5672
getnameinfo: The requested name is valid and was found in the database, but it 
does not have the correct associated data being resolved for.

It doesn't fail immediately after start but only when I attempt to connect with 
send.exe. As a result, the Proton seems to be pretty much not working on my 
machine.

---

The error seems to originate from the function pn_listener_accept in driver.c 
and it translates to WSANO_DATA error / error 11004. I did some digging around 
and playing with the getnameinfo function and it seems to me, that the problem 
is that the getnameinfo function is unable to recognize the service name based 
on the port number. And - according to MSDN 
(http://msdn.microsoft.com/en-us/library/windows/desktop/ms738532(v=vs.85).aspx)
 - that on Windows Server 2003 and earlier results in error (on Windows Vista 
and later this works fine).

If I add a flag NI_NUMERICSERV to the getnameinfo call: 
code = getnameinfo((struct sockaddr *) addr, addrlen, host, 1024, serv, 64, 
NI_NUMERICSERV)
it will not return an error but return success and use the port number as a 
service name. And with this change the recv.exe starts working fine.

However, adding this flag will on Windows Vista and higher and in Linux 
probably result in the service name being always returned as a port number and 
not as a name. So I'm not sure it is desired to add this flag on all platforms. 

Regards
Jakub

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [documentation] -- Intro to Proton

[Jakub Scholz]

Hi Michael,

I know you mentioned plans to write some bigger document ... it is not
entirely clear to me, whether this is supposed to be a standalone
introduction or just a first chapter of the larger document. It suppose the
second is correct, right?

Also, is it introduction to Proton or just to the Proton Messenger API?
From what I understood so far from the discussions here in the mailing
list, Proton is much more than just the Messenger API. I would either call
it Proton Messenger introduction or add some short explanation that the
Messenger API is just one part of Proton which might be the most
interesting for beginners.

Thanks  Regards
Jakub

On Mon, Feb 25, 2013 at 5:15 PM, Michael Goulish mgoul...@redhat.comwrote:

   The messenger interface allows you to use the Secure Sockets Layer
   by exposing an interface to the OpenSSL library.

Re: example of proton documentation

[Jakub Scholz]

Hi Michael,

I'm rather a foreigner in the land of Proton, but that point of view might
make the feedback useful as well :-). As someone who didn't worked with
proton much, I would probably raise following questions ...

a) If I remember correctly, in (some of) the old Qpid APIs the flow control
was able to work as windows based or credit based. From your description it
is not entirely clear to me whether the flow control in Proton is credit or
window based. You talk about credit, but afterwards you mention
the dequeuing using pn_messenger_get(...) function which makes me wonder
whether this call restores the credit. If it is not related to the credit,
I would probably remove the last part of the chapter mentioning the
pn_messenger_get() call. Since flow control is slightly more advanced
topic, I would assume that the pn_messenger_get() should be explained
already in previous chapters.

b) Again, if I remember correctly, (some of) the old Qpid APIs allowed to
specify flow control limits in messages or in bytes. You mention only limit
in messages - that might immediately raise questions how can I specify the
limit in bytes. I think it would be great if you can add a note that the
flow control limit in bytes is not supported.

c) 10 units per link doesn't really sound like infinite credit. People tend
to often read only half of the documentation - many of them might stop
after reading You can also grant 'infinite' credit by using a negative
value and afterwards they will wonder why is it only 10 per link and not
really infinite. I would probably also rename the chapter and/or rephrase
the first sentence.

d) It is not entirely clear to me, whether the infinite credit is then
somehow auto-refreshed or whether the 10 units are consumed by the messages.

e) It remains at the link, and successive calls can increase it. ... can
the credit be really only increased? Or can it be also decreased? I would
suggest to mention it there even if it is not possible to decrease the
credit ... just to avoid questions.

f) It would be great if the typical pattern can be slightly more complex
and include the refreshing of the credit with further
pn_messenger_recv(...) call.

g) Also, I would probably structure the chapters as 1. Controlling Message
Flow with Credit, 1.1 Credit does not drain, 1.2 A typical pattern and 1.3
Infinite credit

Anyway, thanks a lot for your effort ... keep the good work ... without a
good documentation, it doesn't matter how good Proton is - nobody will use
it. When we started with AMQP / Qpid / MRG Messaging, the documentation was
pretty much useless and we had to write our own Programming Guide because
nobody from our customers was able to even connect. It would be great if we
can avoid it in the next version :-).

Thanks  Regards
Jakub


On Fri, Feb 22, 2013 at 11:14 AM, Michael Goulish mgoul...@redhat.comwrote:


   I wonder if anybody out there in Proton Land has an
   opinion about this little piece of Proton doc.

   This is an example of the documentation I'm creating as
   I use the Proton interface to

   I'd be interested to hear about

  1. correctness
  2. clarity
  3. focus
  4. usefulness
  5. anything else that strikes you


 I don't know what to call this -- a mini-tutorial? -- a 'topic'? --
 but in any case, I expect I will have 5 or 6 pieces like this for
 the Proton Messenger doc when I'm done, so I wanted to See What You Think.
 Yes, *you* !


 - everything below this point is the doc -





 Controlling Message Flow with Credit
 =


 To control the flow of messages into your Proton application,
 use the second argument to

 pn_messenger_recv ( messenger, credit );

 If you set credit to a positive value, it will limit the number
 of messages that pn_messenger_recv enqueues for you on that
 call.

 The number you provide is a maximum.  The call to pn_messenger_recv
 may also enqueue fewer messages, or none.  You can learn how many
 were received with:

 pn_messenger_incoming ( messenger );

 You can then dequeue each message, one at a time, into your
 application with successive calls to

 pn_messenger_get ( messenger );




 A typical pattern
 ---

 int i, incoming;

 pn_messenger_recv ( messenger, credit );
 incoming = pn_messenger_incoming ( messenger );
 for ( i = 0; i  incoming; ++ i )
 {
   pn_messenger_get ( messenger, message );
   consume_message ( message );
 }


 Infinite Credit
 --

 You can also grant 'infinite' credit by using a negative
 value as the second arg to pn_messenger_recv().  This will
 have the effect of granting 10 units of credit to every link
 on that call to pn_messenger_recv().

 A single messenger, listening on a single port, may have
 many incoming links.




 Credit does not drain
 --

 Once granted by 

Re: Proton Messenger and the Request/Response pattern

[Jakub Scholz]

Hi Ted,

From my experience I have to agree with you, that the way the
request/response is handled in the current API is a bit complicated and
caused some troubles to some of our customers connecting to our brokers.

But at the same time I like the flexibility of the current approach, where
you have a high level of control about the queues / exchanges used to
deliver the responses. In our use case, when we have a lot of 3rd party
customers connecting to our broker, it is the security and the operability
what is important for us. For example having the response queues to follow
some naming schema based on the user name gives you a quick overview about
which queues belong to which customers and at the same time makes it really
easy to ensure the security using ACLs. Also, when you have a broker where
multiple different clients are connecting, you have to validate the
reply_to address to avoid sending the response(s) to a different customer
(either by mistake or by intention).

Of course the best would be if we can have both - the simplicity as well as
the flexibility. But I'm not sure whether it is possible to add the
flexibility to your proposal without making it too complicated again.
Having some default behavior and some configuration options to affect the
default behavior might be one of the possibilities.

Regards
Jakub


On Wed, Jan 2, 2013 at 8:14 PM, Ted Ross tr...@redhat.com wrote:

 I'd like to start a discussion on how, from an API perspective,
 applications can use the request/response pattern.  If we get this right,
 we will remove a significant barrier to adoption of AMQP.

 Middleware messaging systems typically do a poor job of supporting this
 pattern.  The Qpid APIs are quite lacking in this regard (requester creates
 and subscribes to a temporary queue with a _unique_ name and places this
 name in the reply-to field).

 Proton Messenger supports request/reply (see 
 examples/messenger/$LANG/{**client,server})
 as follows:

 The requester (client) has to put _something_ into the request message's
 reply_to field.  It also sets the correlation_id field if it needs to
 dispatch multiple responses.  The responder (server) must copy the request
 message's reply_to field to the response message's address field and also
 copy the correlation_id.

 This API is good for the case where the client wants the response to go to
 a third party.  In this case the reply_to is well understood to be the
 address of the third party receiver.  However in the more common case where
 the response is intended to come back to the client, it's not clear at all
 what to put in the reply_to field.

 I propose that we allow the client to simply say

 request_msg.reply_expected(**cid)

 (I added the correlation_id argument because it's almost always going to
 be needed).  Further, the server could use

 reply_msg.in_reply_to(request_**msg)

 which would take care of the addresses and the correlation_id.  It also
 provides a place to report an error if a request cannot be replied to
 (absent or invalid reply_to address) rather than force each server
 implementer to code this check.

 Thoughts?

 -Ted


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