[jira] [Created] (QPID-7857) [Java Broker] Invalid routing key
Tomas Vavricka created QPID-7857:
Summary: [Java Broker] Invalid routing key
Key: QPID-7857
URL: https://issues.apache.org/jira/browse/QPID-7857
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: qpid-java-broker-7.0.0
Environment: Java Broker - latest trunk
Qpid JMS client - 0.11.1
Reporter: Tomas Vavricka
Fix For: qpid-java-broker-7.0.0
There is an issue with routing key when sending message to Java Broker. When
ACL rule contains {{routingKey}} constraint Java Broker denies access.
ACL rule:
{noformat}
ACL ALLOW-LOG FIXGW ACCESS VIRTUALHOST
ACL ALLOW-LOG FIXGW PUBLISH EXCHANGE name="request.FIXGW"
routingKey="TradeReport*"
{noformat}
Client code snippet:
{code:java}
TextMessage message = session.createTextMessage("...");
message.setJMSCorrelationID(UUID.randomUUID().toString());
message.setJMSType("TradeReport");
{code}
Java Broker log:
{noformat}
...
2017-07-11 15:55:31,003 DEBUG [IO-/172.23.38.39:40030] (o.a.q.s.s.a.c.RuleSet)
- Checking against rule: Rule[identity='ALL',
action=AclAction[action=Action[operation=All, object=All, properties={}],
firewallRule=null], permission=DENY_LOG]
2017-07-11 15:55:31,003 DEBUG [IO-/172.23.38.39:40030] (o.a.q.s.s.a.c.RuleSet)
- Action matches. Result: DENY_LOG
2017-07-11 15:55:31,003 INFO [IO-/172.23.38.39:40030] (q.m.a.denied) -
[con:2(FIXGW@/172.23.38.39:40030/default)/ch:1] ACL-1002 : Denied : Publish
Exchange {ROUTING_KEY=request.FIXGW, NAME=request.FIXGW,
VIRTUALHOST_NAME=default}
2017-07-11 15:55:31,003 DEBUG [IO-/172.23.38.39:40030]
(o.a.q.s.m.AbstractConfiguredObject) - authorise returned DENIED
2017-07-11 15:55:31,003 DEBUG [IO-/172.23.38.39:40030] (o.a.q.s.p.frame) -
SEND[/172.23.38.39:40030|1] :
Detach{handle=0,closed=true,error=Error{condition=not-allowed,description=Permission
ACTION(publish) is denied for : Exchange 'request.FIXGW' on VirtualHost
'default'}}
2017-07-11 15:55:31,003 DEBUG [IO-/172.23.38.39:40030]
(o.a.q.s.s.d.DerbyMessageStore) - REMOVE called on message: 3
2017-07-11 15:55:31,003 DEBUG [IO-/172.23.38.39:40030]
(o.a.q.s.p.v.f.FrameHandler) - RECV 0 bytes
...
{noformat}
In log there is routing key same as name. But in client was routing key
specified as TradeReport.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-298) Use online service to manage and display coverage reports
[ https://issues.apache.org/jira/browse/QPIDJMS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16082418#comment-16082418 ] ASF GitHub Bot commented on QPIDJMS-298: Github user ctron commented on the issue: https://github.com/apache/qpid-jms/pull/8 It indeed works fine. There is one caveat when converting Jacoco exec files to XML. Only classes of the local module will be reported in the XML files. So when you have a module A which gets tested by module B, then classes from module A will be missing in the XML report of module B, although they are in the exec file of module B. However there is a maven plugin for fixing that: https://ctron.github.io/jacoco-extras/xml-mojo.html 😉 > Use online service to manage and display coverage reports > - > > Key: QPIDJMS-298 > URL: https://issues.apache.org/jira/browse/QPIDJMS-298 > Project: Qpid JMS > Issue Type: Wish > Components: qpid-jms-client, qpid-jms-discovery >Affects Versions: 0.24.0 >Reporter: Jiri Danek >Priority: Minor > > There are multiple coverage monitoring online services that integrate with > popular CI services, like TravisCI. > I propose uploading coverage report from run in TravisCI to some coverage > monitoring service. This way, test coverage will become more visible. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-jms issue #8: QPIDJMS-298 Add coverage report uploading to codecov.io i...
Github user ctron commented on the issue: https://github.com/apache/qpid-jms/pull/8 It indeed works fine. There is one caveat when converting Jacoco exec files to XML. Only classes of the local module will be reported in the XML files. So when you have a module A which gets tested by module B, then classes from module A will be missing in the XML report of module B, although they are in the exec file of module B. However there is a maven plugin for fixing that: https://ctron.github.io/jacoco-extras/xml-mojo.html 😉 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Proposal to create Docker images for Qpid components.
On 29 June 2017 at 17:52, Irina Boverman wrote: > Thank you all who thoughtfully responded to this proposal. This is a > summary as I understood it and my comments regarding these points. > > (1) Qpid community is in favour of creating and maintaining docker images > for cpp/java brokers > and dispatch router. OS choice is less important, as long as the user can > connect to the broker/router port. We only need to support one OS choice. > > I think this is a good start. It covers a use case when someone wants to > test or deploy client apps against broker/router conveniently running as a > docker service. > > I think there might be another use case for those users who want to develop > client apps in a known environment with client libraries already installed > for them to work with. I think the OS choice is important to these users > because they may have a preference/better knowledge of this particular OS. > Please consider this use case. > > (2) Docker images should be of minimal size. > > As a concept, I fully agree with it. However, community support for > official images also makes sense to me. These images go through review and > testing, as well as, get patches for CVEs. There is a whole infrastructure > in place in Fedora to build docker images, etc following best practices > from OCI. > > Official images range in size between 120 to 200 mb, and have 10+ mil of > downloads, so the size does not appear to be an obstacle to adopting them. > It is my opinion that future official images will evolve to be better > aligned with how they are used, for example "server" and "workstation", etc. > > REPOSITORY TAG IMAGE ID > CREATED SIZE > docker.io/ubuntulatest ebcd9d4fca80 > 6 weeks ago 117.9 MB > docker.io/debianlatest e5599115b6a6 > 5 months ago123 MB > docker.io/centoslatest 67591570dd29 > 6 months ago191.8 MB > docker.io/fedoralatest a1e614f0f30e > 6 months ago197.1 MB > > We can also modify the base image to remove some items if we think they are > not needed. > I think using a base OS image is fine, and your text and Justin's link suggests there are likely to be improvements in some regards in this area too. There is also nothing stopping a further image as minimal size option based on Alpine etc, but obviously components would need to work and be supported there first and it wasn't clear that is currently always true. > My personal preference is to start with fedora image because this > distribution has latest upstream releases for qpid packages, and I am the > maintainer for a number of these packages. I think we possibly need some clarity around the end result here, as it could strongly influence this particular area. For images to be considered 'official' Apache Qpid artifacts maintained directly by the project, they and their Qpid related contents would really need to be fully managed in concert with the projects release process. For example, if such an image were utilising packages to incorporate their relevant Qpid bits then I think it follows those packages would similarly need to be considered 'official' and handled similarly. Utilising the Qpid packages from Fedora distributions for example, wouldn't be appropriate in an 'official Apache Qpid' image since they are not directly managed artifacts of the Apache Qpid project. There wouldn't be an issue in simply considering such images to be a community-created convenience binaries based on the projects source release, as e.g. the existing Fedora packages themselves already are, but they wouldn't be considered 'official' Apache Qpid artifacts. It is worth saying this isn't particularly unusual, for example httpd direct people to their source releases but do reference various third party binaries for Windows users, and don't seem to be involved with the docker images for httpd, with members of the docker community instead handling that. I think either approach works here, having distribution based packages obviously has certain advantages for users and the project, so its probably more of a question around what people are actually expecting and/or looking to contribute towards here. > Fedora community is also working on its own docker registry (it will have > stable and test registries), has koji support for building images and > guidelines for naming and versioning them. > > (3). What upstream releases will be dockerised? > > I would like to propose to start with latest released version. We will > maintain at most 1 version at any time. All code necessary to create these > images should be included in the upstream source repository starting with > the next release. We will provide security patches for it as needed (and > possibly will need patch releases). I am not sure if it will be possible to > remove older releases from
[jira] [Commented] (QPID-7856) [Java Broker] Convert broker connection related attributes into context variables and expose them on amqp port as derived attributes
[
https://issues.apache.org/jira/browse/QPID-7856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16082154#comment-16082154
]
Keith Wall commented on QPID-7856:
--
I agree that having a method to influence these settings on a per user (or
group) basis would be ideal, but that is not an option we have at the moment.
I can foresee having the flexibility to have different {{sessionCountLimit}} in
force within a single Broker would be useful - especially when porting large
applications between Qpid JMS Clients. I think, pragmatically, Port is best
home we have at the moment. It will be one of our standard pattern context
variable+derived attribute, so the ability to override at a global level is
maintained. I am happy to add the ability to override for AMQP 1.0 at a
virtualhost level if you think this valuable.
> [Java Broker] Convert broker connection related attributes into context
> variables and expose them on amqp port as derived attributes
>
>
> Key: QPID-7856
> URL: https://issues.apache.org/jira/browse/QPID-7856
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> The current implementation of broker model object interface declares
> connection related attributes "connection.sessionCountLimit",
> "connection.heartBeatDelay", "connection.closeWhenNoRoute". These attributes
> need to be converted into context variables and exposed on AMQP Port as
> derived attributes, as they are only applicable to AMQP connections.
> Additionally, AMQP connection interface needs to expose negotiated
> heartbeat/idle timeouts intervals.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1515) Python sender client doesn't check actual link state and continues to send messages even if link is down
Dmitrii Puzikov created PROTON-1515: --- Summary: Python sender client doesn't check actual link state and continues to send messages even if link is down Key: PROTON-1515 URL: https://issues.apache.org/jira/browse/PROTON-1515 Project: Qpid Proton Issue Type: Bug Components: python-binding Environment: RHEL7.3 Jboss AMQ 7 python-qpid-proton.x86_64-0.14.0-1.el7 Reporter: Dmitrii Puzikov Attachments: sender.log Steps to reproduce: 1. Start broker 2. Create queue 3. Start sending e.g. 10 messages with python sender 4. Kill broker 5. Notice that client continues send messages and raises exception only after all 10 messages were sent. Actual behavior: Python sender client ignores link failure until all messages were sent and only then raises an exception/ begins re-connection attempmts. Expected behavior: Client should stop sending messages and raise exception or try to begin re-connection attempts if reconnect option is set. Please, see sender.log. Global handler was added for event logging purposes. It just prints event/handler name. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7856) [Java Broker] Convert broker connection related attributes into context variables and expose them on amqp port as derived attributes
[ https://issues.apache.org/jira/browse/QPID-7856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7856: - Description: The current implementation of broker model object interface declares connection related attributes "connection.sessionCountLimit", "connection.heartBeatDelay", "connection.closeWhenNoRoute". These attributes need to be converted into context variables and exposed on AMQP Port as derived attributes, as they are only applicable to AMQP connections. Additionally, AMQP connection interface needs to expose negotiated heartbeat/idle timeouts intervals. (was: The current implementation of broker model object interface declares connection related attributes "connection.sessionCountLimit", "connection.heartBeatDelay", "connection.closeWhenNoRoute". These attributes need to be moved into AMQP Port model object interface as they are only applicable to AMQP connections. Additionally, AMQP connection interface needs to expose negotiated heartbeat/idle timeouts intervals.) Summary: [Java Broker] Convert broker connection related attributes into context variables and expose them on amqp port as derived attributes (was: [Java Broker] Move broker connection related attributes into amqp port) > [Java Broker] Convert broker connection related attributes into context > variables and expose them on amqp port as derived attributes > > > Key: QPID-7856 > URL: https://issues.apache.org/jira/browse/QPID-7856 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The current implementation of broker model object interface declares > connection related attributes "connection.sessionCountLimit", > "connection.heartBeatDelay", "connection.closeWhenNoRoute". These attributes > need to be converted into context variables and exposed on AMQP Port as > derived attributes, as they are only applicable to AMQP connections. > Additionally, AMQP connection interface needs to expose negotiated > heartbeat/idle timeouts intervals. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-298) Use online service to manage and display coverage reports
[ https://issues.apache.org/jira/browse/QPIDJMS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16081925#comment-16081925 ] ASF GitHub Bot commented on QPIDJMS-298: Github user codecov-io commented on the issue: https://github.com/apache/qpid-jms/pull/8 # [Codecov](https://codecov.io/gh/apache/qpid-jms/pull/8?src=pr&el=h1) Report > :exclamation: No coverage uploaded for pull request base (`master@ef7241e`). [Click here to learn what that means](https://docs.codecov.io/docs/error-reference#section-missing-base-commit). > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-jms/pull/8?src=pr&el=tree) ```diff @@ Coverage Diff@@ ## master #8 +/- ## Coverage ? 83.4% Complexity?4173 Files ? 204 Lines ? 13208 Branches ?1738 Hits ? 11016 Misses?1643 Partials ? 549 ``` -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-jms/pull/8?src=pr&el=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-jms/pull/8?src=pr&el=footer). Last update [ef7241e...031420f](https://codecov.io/gh/apache/qpid-jms/pull/8?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). > Use online service to manage and display coverage reports > - > > Key: QPIDJMS-298 > URL: https://issues.apache.org/jira/browse/QPIDJMS-298 > Project: Qpid JMS > Issue Type: Wish > Components: qpid-jms-client, qpid-jms-discovery >Affects Versions: 0.24.0 >Reporter: Jiri Danek >Priority: Minor > > There are multiple coverage monitoring online services that integrate with > popular CI services, like TravisCI. > I propose uploading coverage report from run in TravisCI to some coverage > monitoring service. This way, test coverage will become more visible. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Proposal to create Docker images for Qpid components.
On Thu, Jun 29, 2017 at 9:52 AM, Irina Boverman wrote: > Thank you all who thoughtfully responded to this proposal. This is a > summary as I understood it and my comments regarding these points. > > (1) Qpid community is in favour of creating and maintaining docker images > for cpp/java brokers > and dispatch router. OS choice is less important, as long as the user can > connect to the broker/router port. We only need to support one OS choice. > > I think this is a good start. It covers a use case when someone wants to > test or deploy client apps against broker/router conveniently running as a > docker service. > > I think there might be another use case for those users who want to develop > client apps in a known environment with client libraries already installed > for them to work with. I think the OS choice is important to these users > because they may have a preference/better knowledge of this particular OS. > Please consider this use case. > I'm personally interested in doing something for clients. It makes it very easy for folks to evaluate them. This would definitely be a lower priority than the servers, however. > (2) Docker images should be of minimal size. > > As a concept, I fully agree with it. However, community support for > official images also makes sense to me. These images go through review and > testing, as well as, get patches for CVEs. There is a whole infrastructure > in place in Fedora to build docker images, etc following best practices > from OCI. > > Official images range in size between 120 to 200 mb, and have 10+ mil of > downloads, so the size does not appear to be an obstacle to adopting them. > It is my opinion that future official images will evolve to be better > aligned with how they are used, for example "server" and "workstation", > etc. > > REPOSITORY TAG IMAGE ID > CREATED SIZE > docker.io/ubuntulatest ebcd9d4fca80 > 6 weeks ago 117.9 MB > docker.io/debianlatest e5599115b6a6 > 5 months ago123 MB > docker.io/centoslatest 67591570dd29 > 6 months ago191.8 MB > docker.io/fedoralatest a1e614f0f30e > 6 months ago197.1 MB > > We can also modify the base image to remove some items if we think they are > not needed. > > My personal preference is to start with fedora image because this > distribution has latest upstream releases for qpid packages, and I am the > maintainer for a number of these packages. > Fedora community is also working on its own docker registry (it will have > stable and test registries), has koji support for building images and > guidelines for naming and versioning them. > Fedora and others have purpose-built minimal base images for this. I think we should target those. https://fedoraproject.org/wiki/Changes/ContainerMinimalImage
[jira] [Assigned] (PROTON-1505) Message header defaults only work if no header present
[ https://issues.apache.org/jira/browse/PROTON-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned PROTON-1505: --- Assignee: Andrew Stitcher (was: Cliff Jansen) > Message header defaults only work if no header present > -- > > Key: PROTON-1505 > URL: https://issues.apache.org/jira/browse/PROTON-1505 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Kim van der Riet >Assignee: Andrew Stitcher > Fix For: 0.18.0 > > > An error in the qpid-interop-tests JMS headers test showed that where there > is no message priority on the wire, the C++ and Python client APIs do not > return the default value as mandated by the AMQP spec. In particular, the > priority is returned with a value of 0 rather than the default value of 4. > This raises two issues: > 1. Setting the default value (in particularly for priority, where a priority > system may be adopted that is not default, and the missing value may need to > have a value other than 4). > 2. (C++) Gaining access to the transport headers so that there is an ability > to distinguish between the default and the value being actually present on > the wire. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7856) [Java Broker] Move broker connection related attributes into amqp port
[
https://issues.apache.org/jira/browse/QPID-7856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16081966#comment-16081966
]
Keith Wall commented on QPID-7856:
--
That's true. The horrid {{closeWhenNoRoute}} has no meaning for AMQP 1.0 and I
hope it stays that way :). For {{sessionCountLimit}}, we realised that
putting it on Virtualhost wouldn't work for AMQP 0-8..0-10. If modifying on a
per application basis is desirable, we could always have an AMQP 1.0 specific
context var etc on VirtualHost. AMQP 1.0 would then use the VirtualHost value
if set, or otherwise fall back to the value from the Port.I do wonder
though how often this flexibility would be used.
> [Java Broker] Move broker connection related attributes into amqp port
> --
>
> Key: QPID-7856
> URL: https://issues.apache.org/jira/browse/QPID-7856
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Alex Rudyy
> Fix For: qpid-java-broker-7.0.0
>
>
> The current implementation of broker model object interface declares
> connection related attributes "connection.sessionCountLimit",
> "connection.heartBeatDelay", "connection.closeWhenNoRoute". These attributes
> need to be moved into AMQP Port model object interface as they are only
> applicable to AMQP connections. Additionally, AMQP connection interface needs
> to expose negotiated heartbeat/idle timeouts intervals.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1505) Message header defaults only work if no header present
[ https://issues.apache.org/jira/browse/PROTON-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1505: Fix Version/s: 0.18.0 > Message header defaults only work if no header present > -- > > Key: PROTON-1505 > URL: https://issues.apache.org/jira/browse/PROTON-1505 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Kim van der Riet >Assignee: Cliff Jansen > Fix For: 0.18.0 > > > An error in the qpid-interop-tests JMS headers test showed that where there > is no message priority on the wire, the C++ and Python client APIs do not > return the default value as mandated by the AMQP spec. In particular, the > priority is returned with a value of 0 rather than the default value of 4. > This raises two issues: > 1. Setting the default value (in particularly for priority, where a priority > system may be adopted that is not default, and the missing value may need to > have a value other than 4). > 2. (C++) Gaining access to the transport headers so that there is an ability > to distinguish between the default and the value being actually present on > the wire. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7856) [Java Broker] Move broker connection related attributes into amqp port
[ https://issues.apache.org/jira/browse/QPID-7856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16081973#comment-16081973 ] Rob Godfrey commented on QPID-7856: --- Yes - to be honest in a hosted service you might actually want to link the sessionCountLimit to an individual user identity, rather than having the same value for all users on a vhost. Having them as global defaults seems fine... having them set on a per-port basis just seems a little odd (since it's a weird place to set them). > [Java Broker] Move broker connection related attributes into amqp port > -- > > Key: QPID-7856 > URL: https://issues.apache.org/jira/browse/QPID-7856 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The current implementation of broker model object interface declares > connection related attributes "connection.sessionCountLimit", > "connection.heartBeatDelay", "connection.closeWhenNoRoute". These attributes > need to be moved into AMQP Port model object interface as they are only > applicable to AMQP connections. Additionally, AMQP connection interface needs > to expose negotiated heartbeat/idle timeouts intervals. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7856) [Java Broker] Move broker connection related attributes into amqp port
[ https://issues.apache.org/jira/browse/QPID-7856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7856: - Description: The current implementation of broker model object interface declares connection related attributes "connection.sessionCountLimit", "connection.heartBeatDelay", "connection.closeWhenNoRoute". These attributes need to be moved into AMQP Port model object interface as they are only applicable to AMQP connections. Additionally, AMQP connection interface needs to expose negotiated heartbeat/idle timeouts intervals. (was: The current implementation of broker model object interface declares connection related attributes "connection.sessionCountLimit", "connection.heartBeatDelay", "connection.closeWhenNoRoute". This attributes needs to be moved into AMQP Port model object interface as they are only applicable to AMQP connections. Additionally, AMQP connection interface needs to expose negotiated heartbeat/idle timeouts intervals.) > [Java Broker] Move broker connection related attributes into amqp port > -- > > Key: QPID-7856 > URL: https://issues.apache.org/jira/browse/QPID-7856 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The current implementation of broker model object interface declares > connection related attributes "connection.sessionCountLimit", > "connection.heartBeatDelay", "connection.closeWhenNoRoute". These attributes > need to be moved into AMQP Port model object interface as they are only > applicable to AMQP connections. Additionally, AMQP connection interface needs > to expose negotiated heartbeat/idle timeouts intervals. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7856) [Java Broker] Move broker connection related attributes into amqp port
[ https://issues.apache.org/jira/browse/QPID-7856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16081924#comment-16081924 ] Rob Godfrey commented on QPID-7856: --- Moving them to port would mean that you could not set different values for sessionCountLimit / closeWhenNoRoute / etc for different vhosts, no? Obviously this would be true anyway for 0-x protocols (where these values are exchanged before vhost selection), but for 1.0 you might want to set different limits for different vhosts. > [Java Broker] Move broker connection related attributes into amqp port > -- > > Key: QPID-7856 > URL: https://issues.apache.org/jira/browse/QPID-7856 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The current implementation of broker model object interface declares > connection related attributes "connection.sessionCountLimit", > "connection.heartBeatDelay", "connection.closeWhenNoRoute". This attributes > needs to be moved into AMQP Port model object interface as they are only > applicable to AMQP connections. Additionally, AMQP connection interface needs > to expose negotiated heartbeat/idle timeouts intervals. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-jms issue #8: QPIDJMS-298 Add coverage report uploading to codecov.io i...
Github user codecov-io commented on the issue: https://github.com/apache/qpid-jms/pull/8 # [Codecov](https://codecov.io/gh/apache/qpid-jms/pull/8?src=pr&el=h1) Report > :exclamation: No coverage uploaded for pull request base (`master@ef7241e`). [Click here to learn what that means](https://docs.codecov.io/docs/error-reference#section-missing-base-commit). > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-jms/pull/8?src=pr&el=tree) ```diff @@ Coverage Diff@@ ## master #8 +/- ## Coverage ? 83.4% Complexity?4173 Files ? 204 Lines ? 13208 Branches ?1738 Hits ? 11016 Misses?1643 Partials ? 549 ``` -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-jms/pull/8?src=pr&el=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-jms/pull/8?src=pr&el=footer). Last update [ef7241e...031420f](https://codecov.io/gh/apache/qpid-jms/pull/8?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7856) [Java Broker] Move broker connection related attributes into amqp port
[ https://issues.apache.org/jira/browse/QPID-7856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-7856: -- Environment: (was: +underlined text+) > [Java Broker] Move broker connection related attributes into amqp port > -- > > Key: QPID-7856 > URL: https://issues.apache.org/jira/browse/QPID-7856 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The current implementation of broker model object interface declares > connection related attributes "connection.sessionCountLimit", > "connection.heartBeatDelay", "connection.closeWhenNoRoute". This attributes > needs to be moved into AMQP Port model object interface as they are only > applicable to AMQP connections. Additionally, AMQP connection interface needs > to expose negotiated heartbeat/idle timeouts intervals. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7856) [Java Broker] Move broker connection related attributes into amqp port
[ https://issues.apache.org/jira/browse/QPID-7856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7856: - Environment: +underlined text+ Fix Version/s: qpid-java-broker-7.0.0 Component/s: Java Broker Issue Type: Improvement (was: Bug) > [Java Broker] Move broker connection related attributes into amqp port > -- > > Key: QPID-7856 > URL: https://issues.apache.org/jira/browse/QPID-7856 > Project: Qpid > Issue Type: Improvement > Components: Java Broker > Environment: +underlined text+ >Reporter: Alex Rudyy > Fix For: qpid-java-broker-7.0.0 > > > The current implementation of broker model object interface declares > connection related attributes "connection.sessionCountLimit", > "connection.heartBeatDelay", "connection.closeWhenNoRoute". This attributes > needs to be moved into AMQP Port model object interface as they are only > applicable to AMQP connections. Additionally, AMQP connection interface needs > to expose negotiated heartbeat/idle timeouts intervals. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7856) [Java Broker] Move broker connection related attributes into amqp port
Alex Rudyy created QPID-7856: Summary: [Java Broker] Move broker connection related attributes into amqp port Key: QPID-7856 URL: https://issues.apache.org/jira/browse/QPID-7856 Project: Qpid Issue Type: Bug Reporter: Alex Rudyy The current implementation of broker model object interface declares connection related attributes "connection.sessionCountLimit", "connection.heartBeatDelay", "connection.closeWhenNoRoute". This attributes needs to be moved into AMQP Port model object interface as they are only applicable to AMQP connections. Additionally, AMQP connection interface needs to expose negotiated heartbeat/idle timeouts intervals. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-jms pull request #8: QPIDJMS-298 Add coverage report uploading to codec...
GitHub user jdanekrh opened a pull request: https://github.com/apache/qpid-jms/pull/8 QPIDJMS-298 Add coverage report uploading to codecov.io in .travis.yml You can review the report at https://codecov.io/gh/msgqe/qpid-jms/branch/codecov. There is also this nice feature of coverage diffs between commits (works only if both commits had been tested in CI before). It does not show much for this commit, because no java code was changed https://codecov.io/gh/msgqe/qpid-jms/commit/c1db46d8ee19c3eced459d0409eef6b78e4c5dae. The project obviously needs to be enabled for codecov.io. I am not sure if that is a problem or not, given qpid-jms is an Apache project. I choose codecov.io because it seems to have worked well for @ctron in https://github.com/ctron/kapua-gateway-client. You can merge this pull request into a Git repository by running: $ git pull https://github.com/msgqe/qpid-jms codecov Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-jms/pull/8.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #8 commit 031420f0ba63a5e427b827f14e9225d16e9c1eae Author: JiřàDaněk Date: 2017-06-22T10:43:31Z QPIDJMS-298 Add coverage report uploading to codecov.io in .travis.yml --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-298) Use online service to manage and display coverage reports
[ https://issues.apache.org/jira/browse/QPIDJMS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16081894#comment-16081894 ] ASF GitHub Bot commented on QPIDJMS-298: GitHub user jdanekrh opened a pull request: https://github.com/apache/qpid-jms/pull/8 QPIDJMS-298 Add coverage report uploading to codecov.io in .travis.yml You can review the report at https://codecov.io/gh/msgqe/qpid-jms/branch/codecov. There is also this nice feature of coverage diffs between commits (works only if both commits had been tested in CI before). It does not show much for this commit, because no java code was changed https://codecov.io/gh/msgqe/qpid-jms/commit/c1db46d8ee19c3eced459d0409eef6b78e4c5dae. The project obviously needs to be enabled for codecov.io. I am not sure if that is a problem or not, given qpid-jms is an Apache project. I choose codecov.io because it seems to have worked well for @ctron in https://github.com/ctron/kapua-gateway-client. You can merge this pull request into a Git repository by running: $ git pull https://github.com/msgqe/qpid-jms codecov Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-jms/pull/8.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #8 commit 031420f0ba63a5e427b827f14e9225d16e9c1eae Author: Jiřà Daněk Date: 2017-06-22T10:43:31Z QPIDJMS-298 Add coverage report uploading to codecov.io in .travis.yml > Use online service to manage and display coverage reports > - > > Key: QPIDJMS-298 > URL: https://issues.apache.org/jira/browse/QPIDJMS-298 > Project: Qpid JMS > Issue Type: Wish > Components: qpid-jms-client, qpid-jms-discovery >Affects Versions: 0.24.0 >Reporter: Jiri Danek >Priority: Minor > > There are multiple coverage monitoring online services that integrate with > popular CI services, like TravisCI. > I propose uploading coverage report from run in TravisCI to some coverage > monitoring service. This way, test coverage will become more visible. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-298) Use online service to manage and display coverage reports
Jiri Danek created QPIDJMS-298: -- Summary: Use online service to manage and display coverage reports Key: QPIDJMS-298 URL: https://issues.apache.org/jira/browse/QPIDJMS-298 Project: Qpid JMS Issue Type: Wish Components: qpid-jms-client, qpid-jms-discovery Affects Versions: 0.24.0 Reporter: Jiri Danek Priority: Minor There are multiple coverage monitoring online services that integrate with popular CI services, like TravisCI. I propose uploading coverage report from run in TravisCI to some coverage monitoring service. This way, test coverage will become more visible. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
