Re: [VOTE] Release Qpid JMS client 0.20.0

[Timothy Bish]

+1

* Validated the signatures and sums
* Reviewed the License and Notice files
* Reviewed the documentation file
* Built from source and ran the tests
* Used the staged artifacts in the ActiveMQ AMQP test suite
* Ran the provided examples against an ActiveMQ broker

On 01/16/2017 01:38 PM, Robbie Gemmell wrote:

Hi folks,

I have put together a spin for a 0.20.0 Qpid JMS client release,
please test it and vote accordingly.

The source and binary archives can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/jms/0.20.0-rc1/

Those files and the other maven artifacts are also staged for now at:
https://repository.apache.org/content/repositories/orgapacheqpid-1097

Regards,
Robbie


P.S. If you want to test it out using maven (e.g with the examples
src, or your own things), you can temporarily add this to your poms to
access the staging repo:

   
 
   staging
   
https://repository.apache.org/content/repositories/orgapacheqpid-1097
 
   

The dependency for the client itself would then be:

   
 org.apache.qpid
 qpid-jms-client
 0.20.0
   

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





--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/


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

RE: Slow-starting queue visibility and handling it

[Jeff Donner]

Doh. It turned out we had a mismatched queue name. Sorry ...! And thanks. 

Jeff

From: Gordon Sim [g...@redhat.com]
Sent: Monday, January 16, 2017 1:55 AM
To: users@qpid.apache.org
Subject: Re: Slow-starting queue visibility and handling it

On 14/01/17 02:43, Jeff Donner wrote:
>   We're using proton 14, and qpidd 1.35. We probably have bad routing at one 
> spot from a proton client to a qpidd broker on another machine, and the 
> client is slow to see the queue (it fails out with "amqp:no-found"), even 
> though the broker has been running steadily and the ping time is ~500ms. 
> qpid-tool is also slow to see anything - you can type list for 5 seconds 
> before you see any queues (it takes about 5 seconds even run locally, though 
> it can take much longer run remotely). We presume something similar is 
> happening to our proton client (though it looks for a specific queue, so 
> there should be no time spent collecting metainfo).
>
> The client fails instantly - if the client were failing to connect at the TCP 
> level wouldn't TCP just wait for a few seconds?

[...]

> But it doesn't seem to prevent the initial failing. Is the reconnect_timer 
> just for /dropped/ connections?
>
> Is there any mechanism to cope with slow connections? This code all works 
> fine on better-connected machines.

Usually, the amqp:not-found error  is sent back by the broker when the
client tries to attach to a queue that doesn't exist. How is the queue
in question being created?

I don't *think* this has anything to do with 'slowness', if it is indeed
the broker that is sending back that error, as I think it must be. Is it
possible it is somehow connecting to the wrong broker?

You say 'initial failing', does that mean that if it retries it usually
succeeds?

Can you get a protocl trace from the failing client (Run with env var
PN_TRACE_FRM=1)? Or a wireshark trace?


-
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: [VOTE] Release Qpid JMS client 0.20.0

[Timothy Bish]

On 01/16/2017 02:29 PM, Adel Boutros wrote:

Hello Robbie,


Out of curiosity, can you please explain why the release is 0.20.0 and not 
0.12.0?

When will an official 1.0.0 be out?


The main reason for the bump is that this version now implements the JMS 
2.0 API and is therefore a larger shift in features and code changes 
that a version 0.12.0 would imply.


There are no plans for a 1.0.0 release at this time.



Regards,

Adel


From: Robbie Gemmell 
Sent: Monday, January 16, 2017 7:38:04 PM
To: users@qpid.apache.org
Subject: [VOTE] Release Qpid JMS client 0.20.0

Hi folks,

I have put together a spin for a 0.20.0 Qpid JMS client release,
please test it and vote accordingly.

The source and binary archives can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/jms/0.20.0-rc1/

Those files and the other maven artifacts are also staged for now at:
https://repository.apache.org/content/repositories/orgapacheqpid-1097

Regards,
Robbie


P.S. If you want to test it out using maven (e.g with the examples
src, or your own things), you can temporarily add this to your poms to
access the staging repo:

   
 
   staging
   
https://repository.apache.org/content/repositories/orgapacheqpid-1097
 
   

The dependency for the client itself would then be:

   
 org.apache.qpid
 qpid-jms-client
 0.20.0
   

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





--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/


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

Re: [VOTE] Release Qpid JMS client 0.20.0

[Adel Boutros]

Hello Robbie,


Out of curiosity, can you please explain why the release is 0.20.0 and not 
0.12.0?

When will an official 1.0.0 be out?


Regards,

Adel


From: Robbie Gemmell 
Sent: Monday, January 16, 2017 7:38:04 PM
To: users@qpid.apache.org
Subject: [VOTE] Release Qpid JMS client 0.20.0

Hi folks,

I have put together a spin for a 0.20.0 Qpid JMS client release,
please test it and vote accordingly.

The source and binary archives can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/jms/0.20.0-rc1/

Those files and the other maven artifacts are also staged for now at:
https://repository.apache.org/content/repositories/orgapacheqpid-1097

Regards,
Robbie


P.S. If you want to test it out using maven (e.g with the examples
src, or your own things), you can temporarily add this to your poms to
access the staging repo:

  

  staging
  
https://repository.apache.org/content/repositories/orgapacheqpid-1097

  

The dependency for the client itself would then be:

  
org.apache.qpid
qpid-jms-client
0.20.0
  

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

Re: [Proton 0.16.0] Compiling Proton Python bindings on Solaris is failing in the python tests

[Ken Giusti]

Adel - 

I've hit this error before and it was due to a mix up with my library paths.

When I got that error my 2.7 python env was trying to load the .so built using 
the python3 library.

Can you run strace on the test to see exactly which _cproton.so is being loaded?

-K


- Original Message -
> From: "Adel Boutros" 
> To: users@qpid.apache.org
> Sent: Monday, January 16, 2017 1:28:36 PM
> Subject: Re: [Proton 0.16.0] Compiling Proton Python bindings on Solaris is 
> failing in the python tests
> 
> I just compiled SWIG 1.3.40 on Solaris and tried but still got the same error
> :(
> 
> 
> From: Adel Boutros 
> Sent: Monday, January 16, 2017 7:00:41 PM
> To: users@qpid.apache.org
> Subject: [Proton 0.16.0] Compiling Proton Python bindings on Solaris is
> failing in the python tests
> 
> Hello,
> 
> 
> I am actually trying to activate the python bindings in Proton so I can
> compile Dispatch Router on Solaris. However, the python unit tests of Proton
> are failing.
> 
> Cmake Configuration
> 
> 
> 
> Found PythonInterp: /bin/python (found version "2.7.9")
> Found SWIG: /bin/swig (found version "2.0.9")
> Found CyrusSASL: /lib/64/libsasl2.so
> Found PythonLibs: /libpython2.7.so (found suitable exact version "2.7.9")
> Could NOT find Ruby (missing:  RUBY_EXECUTABLE RUBY_INCLUDE_DIR RUBY_LIBRARY)
> 
> 
> Error (tests/python/proton-test)
> 
> -
> 
> 1:   File "/build-dir/proton/proton-c/bindings/python/cproton.py", line
> 22, in swig_import_helper
> 1: _mod = imp.load_module('_cproton', fp, pathname, description)
> 1: ImportError: dynamic module does not define init function (init_cproton)
> 
> 
> Analysis
> 
> 
> 
> Listing symbols in _cproton.so shows the above function is available
> 
> nm _cproton.so  | grep init_cproton
> [62]|340924|5677|FUNC |LOCL |2|13 |init_cproton
> 
> 
> I suspect SWIG version (2.0.9) to be the culprit however I am not pretty sure
> if it related. On Linux, I am using SWIG version 1.3.40 and it is working.
> 
> I am actually out of ideas. So any help is highly appreciated!
> 
> 
> PS: I am compiling in 64-bit mode in case it helps.
> 
> 
> Regards,
> 
> Adel
> 

-- 
-K

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

[VOTE] Release Qpid JMS client 0.20.0

[Robbie Gemmell]

Hi folks,

I have put together a spin for a 0.20.0 Qpid JMS client release,
please test it and vote accordingly.

The source and binary archives can be grabbed from:
https://dist.apache.org/repos/dist/dev/qpid/jms/0.20.0-rc1/

Those files and the other maven artifacts are also staged for now at:
https://repository.apache.org/content/repositories/orgapacheqpid-1097

Regards,
Robbie


P.S. If you want to test it out using maven (e.g with the examples
src, or your own things), you can temporarily add this to your poms to
access the staging repo:

  

  staging
  
https://repository.apache.org/content/repositories/orgapacheqpid-1097

  

The dependency for the client itself would then be:

  
org.apache.qpid
qpid-jms-client
0.20.0
  

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

Re: [Proton 0.16.0] Compiling Proton Python bindings on Solaris is failing in the python tests

[Adel Boutros]

I just compiled SWIG 1.3.40 on Solaris and tried but still got the same error :(


From: Adel Boutros 
Sent: Monday, January 16, 2017 7:00:41 PM
To: users@qpid.apache.org
Subject: [Proton 0.16.0] Compiling Proton Python bindings on Solaris is failing 
in the python tests

Hello,


I am actually trying to activate the python bindings in Proton so I can compile 
Dispatch Router on Solaris. However, the python unit tests of Proton are 
failing.

Cmake Configuration



Found PythonInterp: /bin/python (found version "2.7.9")
Found SWIG: /bin/swig (found version "2.0.9")
Found CyrusSASL: /lib/64/libsasl2.so
Found PythonLibs: /libpython2.7.so (found suitable exact version "2.7.9")
Could NOT find Ruby (missing:  RUBY_EXECUTABLE RUBY_INCLUDE_DIR RUBY_LIBRARY)


Error (tests/python/proton-test)

-

1:   File "/build-dir/proton/proton-c/bindings/python/cproton.py", line 22, 
in swig_import_helper
1: _mod = imp.load_module('_cproton', fp, pathname, description)
1: ImportError: dynamic module does not define init function (init_cproton)


Analysis



Listing symbols in _cproton.so shows the above function is available

nm _cproton.so  | grep init_cproton
[62]|340924|5677|FUNC |LOCL |2|13 |init_cproton


I suspect SWIG version (2.0.9) to be the culprit however I am not pretty sure 
if it related. On Linux, I am using SWIG version 1.3.40 and it is working.

I am actually out of ideas. So any help is highly appreciated!


PS: I am compiling in 64-bit mode in case it helps.


Regards,

Adel

[Proton 0.16.0] Compiling Proton Python bindings on Solaris is failing in the python tests

[Adel Boutros]

Hello,


I am actually trying to activate the python bindings in Proton so I can compile 
Dispatch Router on Solaris. However, the python unit tests of Proton are 
failing.

Cmake Configuration



Found PythonInterp: /bin/python (found version "2.7.9")
Found SWIG: /bin/swig (found version "2.0.9")
Found CyrusSASL: /lib/64/libsasl2.so
Found PythonLibs: /libpython2.7.so (found suitable exact version "2.7.9")
Could NOT find Ruby (missing:  RUBY_EXECUTABLE RUBY_INCLUDE_DIR RUBY_LIBRARY)


Error (tests/python/proton-test)

-

1:   File "/build-dir/proton/proton-c/bindings/python/cproton.py", line 22, 
in swig_import_helper
1: _mod = imp.load_module('_cproton', fp, pathname, description)
1: ImportError: dynamic module does not define init function (init_cproton)


Analysis



Listing symbols in _cproton.so shows the above function is available

nm _cproton.so  | grep init_cproton
[62]|340924|5677|FUNC |LOCL |2|13 |init_cproton


I suspect SWIG version (2.0.9) to be the culprit however I am not pretty sure 
if it related. On Linux, I am using SWIG version 1.3.40 and it is working.

I am actually out of ideas. So any help is highly appreciated!


PS: I am compiling in 64-bit mode in case it helps.


Regards,

Adel

Re: [Dispatch Router] Dispatch router not able to use Proton 0.16.0

[Adel Boutros]

Thank you Ganesh!


Regards,

Adel


From: Ganesh Murthy 
Sent: Monday, January 16, 2017 3:37:08 PM
To: users@qpid.apache.org
Subject: Re: [Dispatch Router] Dispatch router not able to use Proton 0.16.0

Hi Adel,
This problem has been fixed on the master branch via 
https://issues.apache.org/jira/browse/DISPATCH-569

It will be available in the 0.8.0 release of the Dispatch Router.

Thanks.

- Original Message -
> From: "Adel Boutros" 
> To: users@qpid.apache.org
> Sent: Monday, January 16, 2017 4:09:53 AM
> Subject: [Dispatch Router] Dispatch router not able to use Proton 0.16.0
>
> Hello,
>
>
> I was trying to compile the Dispatch Router to use Proton 0.16.0 however the
> compilation failed because it seems the code is not yet adapted to the
> newest version of Proton. Is there some work to make it work on this version
> of Proton?
>
>
> The error seems to be related to
> https://github.com/apache/qpid-proton/commit/aadfcbbb7a7b75eb442df4d4de8ef97eb2e7a754
>
>
> PS: As a workaround, I can disable this error but I prefer to check with you
> before doing so to make sure it has no impact (-Wno-error=switch).
>
>
> Errors
>
> ---
>
> container.c: In function 'pn_event_handler':
> container.c:373:5: error: enumeration value 'PN_CONNECTION_WAKE' not handled
> in switch [-Werror=switch]
>  switch (pn_event_type(event)) {
>  ^
> container.c:373:5: error: enumeration value 'PN_LISTENER_ACCEPT' not handled
> in switch [-Werror=switch]
> container.c:373:5: error: enumeration value 'PN_LISTENER_CLOSE' not handled
> in switch [-Werror=switch]
> container.c:373:5: error: enumeration value 'PN_PROACTOR_INTERRUPT' not
> handled in switch [-Werror=switch]
> container.c:373:5: error: enumeration value 'PN_PROACTOR_TIMEOUT' not handled
> in switch [-Werror=switch]
> container.c:373:5: error: enumeration value 'PN_PROACTOR_INACTIVE' not
> handled in switch [-Werror=switch]
>
>
> Regards,
>
> Adel
>

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

Re: [Dispatch Router] Dispatch router not able to use Proton 0.16.0

[Ganesh Murthy]

Hi Adel,
This problem has been fixed on the master branch via 
https://issues.apache.org/jira/browse/DISPATCH-569

It will be available in the 0.8.0 release of the Dispatch Router.

Thanks.

- Original Message -
> From: "Adel Boutros" 
> To: users@qpid.apache.org
> Sent: Monday, January 16, 2017 4:09:53 AM
> Subject: [Dispatch Router] Dispatch router not able to use Proton 0.16.0
> 
> Hello,
> 
> 
> I was trying to compile the Dispatch Router to use Proton 0.16.0 however the
> compilation failed because it seems the code is not yet adapted to the
> newest version of Proton. Is there some work to make it work on this version
> of Proton?
> 
> 
> The error seems to be related to
> https://github.com/apache/qpid-proton/commit/aadfcbbb7a7b75eb442df4d4de8ef97eb2e7a754
> 
> 
> PS: As a workaround, I can disable this error but I prefer to check with you
> before doing so to make sure it has no impact (-Wno-error=switch).
> 
> 
> Errors
> 
> ---
> 
> container.c: In function 'pn_event_handler':
> container.c:373:5: error: enumeration value 'PN_CONNECTION_WAKE' not handled
> in switch [-Werror=switch]
>  switch (pn_event_type(event)) {
>  ^
> container.c:373:5: error: enumeration value 'PN_LISTENER_ACCEPT' not handled
> in switch [-Werror=switch]
> container.c:373:5: error: enumeration value 'PN_LISTENER_CLOSE' not handled
> in switch [-Werror=switch]
> container.c:373:5: error: enumeration value 'PN_PROACTOR_INTERRUPT' not
> handled in switch [-Werror=switch]
> container.c:373:5: error: enumeration value 'PN_PROACTOR_TIMEOUT' not handled
> in switch [-Werror=switch]
> container.c:373:5: error: enumeration value 'PN_PROACTOR_INACTIVE' not
> handled in switch [-Werror=switch]
> 
> 
> Regards,
> 
> Adel
> 

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

Re: Slow-starting queue visibility and handling it

[Gordon Sim]

On 14/01/17 02:43, Jeff Donner wrote:

  We're using proton 14, and qpidd 1.35. We probably have bad routing at one spot from a 
proton client to a qpidd broker on another machine, and the client is slow to see the 
queue (it fails out with "amqp:no-found"), even though the broker has been 
running steadily and the ping time is ~500ms. qpid-tool is also slow to see anything - 
you can type list for 5 seconds before you see any queues (it takes about 5 seconds even 
run locally, though it can take much longer run remotely). We presume something similar 
is happening to our proton client (though it looks for a specific queue, so there should 
be no time spent collecting metainfo).

The client fails instantly - if the client were failing to connect at the TCP 
level wouldn't TCP just wait for a few seconds?


[...]


But it doesn't seem to prevent the initial failing. Is the reconnect_timer just 
for /dropped/ connections?

Is there any mechanism to cope with slow connections? This code all works fine 
on better-connected machines.


Usually, the amqp:not-found error  is sent back by the broker when the 
client tries to attach to a queue that doesn't exist. How is the queue 
in question being created?


I don't *think* this has anything to do with 'slowness', if it is indeed 
the broker that is sending back that error, as I think it must be. Is it 
possible it is somehow connecting to the wrong broker?


You say 'initial failing', does that mean that if it retries it usually 
succeeds?


Can you get a protocl trace from the failing client (Run with env var 
PN_TRACE_FRM=1)? Or a wireshark trace?



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

[Dispatch Router] Dispatch router not able to use Proton 0.16.0

[Adel Boutros]

Hello,


I was trying to compile the Dispatch Router to use Proton 0.16.0 however the 
compilation failed because it seems the code is not yet adapted to the newest 
version of Proton. Is there some work to make it work on this version of Proton?


The error seems to be related to 
https://github.com/apache/qpid-proton/commit/aadfcbbb7a7b75eb442df4d4de8ef97eb2e7a754


PS: As a workaround, I can disable this error but I prefer to check with you 
before doing so to make sure it has no impact (-Wno-error=switch).


Errors

---

container.c: In function 'pn_event_handler':
container.c:373:5: error: enumeration value 'PN_CONNECTION_WAKE' not handled in 
switch [-Werror=switch]
 switch (pn_event_type(event)) {
 ^
container.c:373:5: error: enumeration value 'PN_LISTENER_ACCEPT' not handled in 
switch [-Werror=switch]
container.c:373:5: error: enumeration value 'PN_LISTENER_CLOSE' not handled in 
switch [-Werror=switch]
container.c:373:5: error: enumeration value 'PN_PROACTOR_INTERRUPT' not handled 
in switch [-Werror=switch]
container.c:373:5: error: enumeration value 'PN_PROACTOR_TIMEOUT' not handled 
in switch [-Werror=switch]
container.c:373:5: error: enumeration value 'PN_PROACTOR_INACTIVE' not handled 
in switch [-Werror=switch]


Regards,

Adel