[jira] [Created] (QPID-8580) [Broker-J] Upgrade Broker-J dependencies to the latest version
Alex Rudyy created QPID-8580: Summary: [Broker-J] Upgrade Broker-J dependencies to the latest version Key: QPID-8580 URL: https://issues.apache.org/jira/browse/QPID-8580 Project: Qpid Issue Type: Bug Components: Broker-J Reporter: Alex Rudyy Fix For: qpid-java-broker-8.0.7 Upgrade Qpid Broker dependencies to the latest versions: * jetty 9.4.45.v20220203 * jackson 2.13.2 * slf4j 1.7.36 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8576) BDB HA Virtual Host start-up can hang when majority is lost during message store recovery operations
Alex Rudyy created QPID-8576:
Summary: BDB HA Virtual Host start-up can hang when majority is
lost during message store recovery operations
Key: QPID-8576
URL: https://issues.apache.org/jira/browse/QPID-8576
Project: Qpid
Issue Type: Bug
Components: Broker-J
Affects Versions: qpid-java-broker-8.0.6
Reporter: Alex Rudyy
There is a risk of BDB HA Virtual Host start-up hanging when replica majority
is lost during message store recovery operations. The stack trace like below is
reported for the issue
{noformat}
2022-02-07 11:08:42,086 INFO [VirtualHostNode-node1-Config]
(q.m.h.quorum_lost) - [Broker] [grp(/myha)/vhn(/node1)] HA-1009 : Insufficient
replicas contactable
2022-02-07 11:08:42,087 ERROR [VirtualHostNode-node1-Config]
(o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name 'myha'.
Object will be put into ERROR state.
org.apache.qpid.server.util.ConnectionScopedRuntimeException: Required number
of nodes not reachable
at
org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.handleDatabaseException(ReplicatedEnvironmentFacade.java:496)
at
org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.commit(ReplicatedEnvironmentFacade.java:333)
at
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.removeMessage(AbstractBDBMessageStore.java:354)
at
org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage.remove(AbstractBDBMessageStore.java:1205)
at
org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:136)
at
org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2811)
at
org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2757)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1526)
at
org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1505)
at
org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1072)
at
org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1066)
at
org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2894)
at
org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2890)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at
org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2889)
at
com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1078)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
at
com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:1164)
at
com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:708)
at
com.google.common.util.concurrent.AbstractFuture$TrustedFuture.addListener(AbstractFuture.java:113)
at
com.google.common.util.concurrent.Futures.addCallback(Futures.java:1045)
at
org.apache.qpid.server.model.AbstractConfiguredObject.addFutureCallback(AbstractConfiguredObject.java:2884)
at
org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:1065)
at
org.apache.qpid.server.model.AbstractConfiguredObject.access$600(AbstractConfiguredObject.java:97)
at
org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:591)
at
org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:578)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:639)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl
[jira] [Created] (QPID-8575) [Broker-J] The BDB HA VirtualHostNode can fail to start due to BDB JE Environment recovery NumberFormatException
Alex Rudyy created QPID-8575:
Summary: [Broker-J] The BDB HA VirtualHostNode can fail to start
due to BDB JE Environment recovery NumberFormatException
Key: QPID-8575
URL: https://issues.apache.org/jira/browse/QPID-8575
Project: Qpid
Issue Type: Bug
Components: Broker-J
Affects Versions: qpid-java-broker-8.0.6
Reporter: Alex Rudyy
BDB JE ReplicatedEnvironment recovery can fail with NumberFormatException as
below
{noformat}
Caused by: java.lang.NumberFormatException: For input string: "12370247684"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:583)
at java.lang.Integer.parseInt(Integer.java:615)
at
com.sleepycat.je.rep.InsufficientLogException.(InsufficientLogException.java:218)
at
com.sleepycat.je.rep.impl.RepImpl.handleRestoreRequired(RepImpl.java:2298)
at
com.sleepycat.je.recovery.RecoveryManager.findEndOfLog(RecoveryManager.java:543)
at
com.sleepycat.je.recovery.RecoveryManager.recover(RecoveryManager.java:339)
at
com.sleepycat.je.dbi.EnvironmentImpl.finishInit(EnvironmentImpl.java:841)
at com.sleepycat.je.dbi.DbEnvPool.getEnvironment(DbEnvPool.java:222)
at
com.sleepycat.je.Environment.makeEnvironmentImpl(Environment.java:267)
at com.sleepycat.je.Environment.(Environment.java:252)
at
com.sleepycat.je.rep.ReplicatedEnvironment.(ReplicatedEnvironment.java:607)
at
com.sleepycat.je.rep.ReplicatedEnvironment.(ReplicatedEnvironment.java:466)
at
com.sleepycat.je.rep.ReplicatedEnvironment.(ReplicatedEnvironment.java:540)
{noformat}
It seems that BDB JE version has a defect causing an integer overflow whilst
recovering the environment.
This issue is raised just for tracking purposes. It is not a defect in Qpid
code.
[https://community.oracle.com/tech/developers/discussion/4494512/replicatedenvironment-recovery-can-fail-with-numberformatexception/p1?new=1]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[ANNOUNCE] Apache Qpid Broker-J 8.0.6 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid Broker-J 8.0.6. This is the latest release of pure java implementation of messaging broker supporting the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org) and legacy AMQP protocols 0-10, 0-91, 0-9 and 0-8. Please visit Qpid project site for more details: http://qpid.apache.org/components/broker-j/index.html The release is available now from our website: http://qpid.apache.org/download.html The release brings bug fixes and improvements. The release notes can be found at: http://qpid.apache.org/releases/qpid-broker-j-8.0.6/release-notes.html Thanks to all involved, Qpid Team - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-8561) [Broker-J] Release Qpid Broker-J 8.0.6
[ https://issues.apache.org/jira/browse/QPID-8561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy closed QPID-8561. Resolution: Fixed > [Broker-J] Release Qpid Broker-J 8.0.6 > -- > > Key: QPID-8561 > URL: https://issues.apache.org/jira/browse/QPID-8561 > Project: Qpid > Issue Type: Task > Components: Broker-J > Reporter: Alex Rudyy > Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > > Release Qpid Broker-J 8.0.6 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8560) [Broker-J] Upgrade fasterxml jackson dependency
[ https://issues.apache.org/jira/browse/QPID-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8560: - Issue Type: Improvement (was: Bug) > [Broker-J] Upgrade fasterxml jackson dependency > --- > > Key: QPID-8560 > URL: https://issues.apache.org/jira/browse/QPID-8560 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > > A new version of fasterxml jackson library has been released - 2.12.4. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8500) [Broker-J] Introduce a switch to disable coalescing committer in BDB HA message store
[
https://issues.apache.org/jira/browse/QPID-8500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17406280#comment-17406280
]
Alex Rudyy commented on QPID-8500:
--
Hi [~1025524...@qq.com],
Thanks for testing HA with different durabilities. Please note that we did not
upgrade bdb to version 7.5.11 due to unexpected behaviour. The environment does
not open when only one file is left on disk (It looks like a defect to me). The
bigger issue with version 7.5.11 is that it does not delete obsolete files.
Perhaps, we need to change some JE settings to enforce the file deletion. It is
not exactly clear why the bdb je files gets accumulated.
> [Broker-J] Introduce a switch to disable coalescing committer in BDB HA
> message store
> -
>
> Key: QPID-8500
> URL: https://issues.apache.org/jira/browse/QPID-8500
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.4, qpid-java-broker-7.1.12
>
>
> A BDB JE replication Feeder fails sporadically with errors like the one below
> {noformat}
> Halted log file reading at file 0x7472c8 offset 0x199d07
> offset(decimal)=1678599 prev=0x199cd5:
> entry=DEL_LN_TXtype=31,version=14)
> prev=0x199cd5
> size=44
> Next entry should be at 0x199d49
> com.sleepycat.je.EnvironmentFailureException: (JE 7.4.5) want to read
> 52,431,066,320 but reader at 52,431,066,327 UNEXPECTED_STATE: Unexpected
> internal state, may have side effects.
> at
> com.sleepycat.je.EnvironmentFailureException.unexpectedState(EnvironmentFailureException.java:428)
> at
> com.sleepycat.je.rep.stream.FeederReader.checkForPassingTarget(FeederReader.java:297)
> at
> com.sleepycat.je.rep.stream.FeederReader.isTargetEntry(FeederReader.java:317)
> at
> com.sleepycat.je.log.FileReader.readNextEntryAllowExceptions(FileReader.java:332)
> at com.sleepycat.je.log.FileReader.readNextEntry(FileReader.java:245)
> at
> com.sleepycat.je.rep.stream.FeederReader.scanForwards(FeederReader.java:280)
> at
> com.sleepycat.je.rep.stream.MasterFeederSource.getWireRecord(MasterFeederSource.java:70)
> at
> com.sleepycat.je.rep.impl.node.Feeder$OutputThread.writeAvailableEntries(Feeder.java:1266)
> at
> com.sleepycat.je.rep.impl.node.Feeder$OutputThread.run(Feeder.java:1144)
> {noformat}
> Based on discussion at
> [https://community.oracle.com/tech/developers/discussion/4300421/master-fails-unexpectedly-due-to-feeder-output-halted-log-file-reading-at-file-0x334f63-offset-0x8ce]
> we need a way to configure broker without a coalescing committer. The local
> sync policy would be set as per user virtual host settings.
> A context variable can be added into BDB HA to disable coalescing committer
> thread.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8561) [Broker-J] Release Qpid Broker-J 8.0.6
[ https://issues.apache.org/jira/browse/QPID-8561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-8561: Assignee: Alex Rudyy > [Broker-J] Release Qpid Broker-J 8.0.6 > -- > > Key: QPID-8561 > URL: https://issues.apache.org/jira/browse/QPID-8561 > Project: Qpid > Issue Type: Task > Components: Broker-J > Reporter: Alex Rudyy > Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > > Release Qpid Broker-J 8.0.6 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8554) [Broker-J] Infinite loop in CachingSecurityToken class
[
https://issues.apache.org/jira/browse/QPID-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404008#comment-17404008
]
Alex Rudyy commented on QPID-8554:
--
Hi [~lacam],
{quote}
Why would the method CachingSecurityToken::authorise have the input argument
RuleBasedAccessControl ruleBasedAccessControl if it was always invoked with the
same RuleBasedAccessControl ?
{quote}
The ACL rules can be reloaded using management operation "reload" on ACL
provider. Hence, the RuleBasedAccessControl can be changed. I hope this answer
your question.
> [Broker-J] Infinite loop in CachingSecurityToken class
> --
>
> Key: QPID-8554
> URL: https://issues.apache.org/jira/browse/QPID-8554
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Marek Laca
>Priority: Minor
> Labels: Broker, Java, thread-safe
>
> The CachingSecurityToken class is caching the authorization results. It can
> be utilized by multiple threads at the same time. Hence, it has to be
> multi-thread safe. The CachingSecurityToken::authorise could get stuck in an
> infinite loop when multiple threads try to update the local cache
> simultaneously.
> Two threads can be in permanent conflict when each thread is trying to
> override changes of another thread.
> {code:java}
> AccessControlCache cache;
> while((cache = CACHE_UPDATE.get(this)).getAccessControl() !=
> ruleBasedAccessControl)
> {
> CACHE_UPDATE.compareAndSet(this, cache, new
> AccessControlCache(ruleBasedAccessControl));
> }
> {code}
> Suppose two threads, the thread A and B in following scenario with steps:
> The thread A run into the loop:
> 1. Thread A checks the condition and the 'accessControl' in the cache differs
> from its local value 'ruleBasedAccessControl', let label it as accessControlA.
> 2. Thread A updates the cache with local value accessControlA.
> The thread B run into the loop:
> 3. Thread B checks the condition and the 'accessControl' in the cache differs
> from its local value 'ruleBasedAccessControl', let label it as accessControlB.
> 4. Thread B updates the cache with local value accessControlB.
> The thread A starts the next iteration of the loop:
> 5. Thread A checks the condition and the 'accessControl' in the cache is
> accessControlB, it differs from its local value accessControlA.
> 6. Thread A updates the cache with local value accessControlA.
> The thread B starts the next iteration of the loop:
> 7. Thread B checks the condition and the 'accessControl' in the cache is
> accessControlA, it differs from its local value accessControlB.
> 8. Thread B updates the cache with local value accessControlB.
> The steps 5-8 can repeat forever. Each thread finds in the cache the value
> from another thread and update cache with its own.
> The code does not have any guarantee after how many iterations the loop ends.
> The probability of the endless competition increases with number of threads.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8554) [Broker-J] Infinite loop in CachingSecurityToken class
[
https://issues.apache.org/jira/browse/QPID-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17403434#comment-17403434
]
Alex Rudyy edited comment on QPID-8554 at 8/23/21, 11:48 PM:
-
Hi [~lacam],
I am still struggling to understand an impact of the reported issue.
The {{CachingSecurityToken}} is used mainly to cache authorization results for
publishing operations. The token are session based. Thus, as far as I
understand the tokens are only used in IO threads. I do not see how the same
token can be invoked from multiple IO threads. Could you please provide the
stack traces for the issue?
was (Author: alex.rufous):
Hi [~lacam],
I am still struggling to understand an impact of the reported issue.
The {CachingSecurityToken} is used mainly to cache authorization results for
publishing operations. The token are session based. Thus, as far as I
understand the tokens are only used in IO threads. I do not see how the same
token can be invoked from multiple IO threads. Could you please provide the
stack traces for the issue?
> [Broker-J] Infinite loop in CachingSecurityToken class
> --
>
> Key: QPID-8554
> URL: https://issues.apache.org/jira/browse/QPID-8554
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Marek Laca
>Priority: Minor
> Labels: Broker, Java, thread-safe
>
> The CachingSecurityToken class is caching the authorization results. It can
> be utilized by multiple threads at the same time. Hence, it has to be
> multi-thread safe. The CachingSecurityToken::authorise could get stuck in an
> infinite loop when multiple threads try to update the local cache
> simultaneously.
> Two threads can be in permanent conflict when each thread is trying to
> override changes of another thread.
> {code:java}
> AccessControlCache cache;
> while((cache = CACHE_UPDATE.get(this)).getAccessControl() !=
> ruleBasedAccessControl)
> {
> CACHE_UPDATE.compareAndSet(this, cache, new
> AccessControlCache(ruleBasedAccessControl));
> }
> {code}
> Suppose two threads, the thread A and B in following scenario with steps:
> The thread A run into the loop:
> 1. Thread A checks the condition and the 'accessControl' in the cache differs
> from its local value 'ruleBasedAccessControl', let label it as accessControlA.
> 2. Thread A updates the cache with local value accessControlA.
> The thread B run into the loop:
> 3. Thread B checks the condition and the 'accessControl' in the cache differs
> from its local value 'ruleBasedAccessControl', let label it as accessControlB.
> 4. Thread B updates the cache with local value accessControlB.
> The thread A starts the next iteration of the loop:
> 5. Thread A checks the condition and the 'accessControl' in the cache is
> accessControlB, it differs from its local value accessControlA.
> 6. Thread A updates the cache with local value accessControlA.
> The thread B starts the next iteration of the loop:
> 7. Thread B checks the condition and the 'accessControl' in the cache is
> accessControlA, it differs from its local value accessControlB.
> 8. Thread B updates the cache with local value accessControlB.
> The steps 5-8 can repeat forever. Each thread finds in the cache the value
> from another thread and update cache with its own.
> The code does not have any guarantee after how many iterations the loop ends.
> The probability of the endless competition increases with number of threads.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8554) [Broker-J] Infinite loop in CachingSecurityToken class
[
https://issues.apache.org/jira/browse/QPID-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17403434#comment-17403434
]
Alex Rudyy commented on QPID-8554:
--
Hi [~lacam],
I am still struggling to understand an impact of the reported issue.
The {CachingSecurityToken} is used mainly to cache authorization results for
publishing operations. The token are session based. Thus, as far as I
understand the tokens are only used in IO threads. I do not see how the same
token can be invoked from multiple IO threads. Could you please provide the
stack traces for the issue?
> [Broker-J] Infinite loop in CachingSecurityToken class
> --
>
> Key: QPID-8554
> URL: https://issues.apache.org/jira/browse/QPID-8554
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Marek Laca
>Priority: Minor
> Labels: Broker, Java, thread-safe
>
> The CachingSecurityToken class is caching the authorization results. It can
> be utilized by multiple threads at the same time. Hence, it has to be
> multi-thread safe. The CachingSecurityToken::authorise could get stuck in an
> infinite loop when multiple threads try to update the local cache
> simultaneously.
> Two threads can be in permanent conflict when each thread is trying to
> override changes of another thread.
> {code:java}
> AccessControlCache cache;
> while((cache = CACHE_UPDATE.get(this)).getAccessControl() !=
> ruleBasedAccessControl)
> {
> CACHE_UPDATE.compareAndSet(this, cache, new
> AccessControlCache(ruleBasedAccessControl));
> }
> {code}
> Suppose two threads, the thread A and B in following scenario with steps:
> The thread A run into the loop:
> 1. Thread A checks the condition and the 'accessControl' in the cache differs
> from its local value 'ruleBasedAccessControl', let label it as accessControlA.
> 2. Thread A updates the cache with local value accessControlA.
> The thread B run into the loop:
> 3. Thread B checks the condition and the 'accessControl' in the cache differs
> from its local value 'ruleBasedAccessControl', let label it as accessControlB.
> 4. Thread B updates the cache with local value accessControlB.
> The thread A starts the next iteration of the loop:
> 5. Thread A checks the condition and the 'accessControl' in the cache is
> accessControlB, it differs from its local value accessControlA.
> 6. Thread A updates the cache with local value accessControlA.
> The thread B starts the next iteration of the loop:
> 7. Thread B checks the condition and the 'accessControl' in the cache is
> accessControlA, it differs from its local value accessControlB.
> 8. Thread B updates the cache with local value accessControlB.
> The steps 5-8 can repeat forever. Each thread finds in the cache the value
> from another thread and update cache with its own.
> The code does not have any guarantee after how many iterations the loop ends.
> The probability of the endless competition increases with number of threads.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8500) [Broker-J] Introduce a switch to disable coalescing committer in BDB HA message store
[
https://issues.apache.org/jira/browse/QPID-8500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402875#comment-17402875
]
Alex Rudyy commented on QPID-8500:
--
Hi [~1025524...@qq.com],
My current understanding of the reported issue is that the feeder replication
fails because replicated data has not been synced to disk, but the feeder tried
to read the data from the disk before it was fully written. In general, I
believe that it is a defect in BDB JE library used by Qpid for implementation
of HA. Thus, the issue should be fixed there. The implemented change is
essentially an attempt to work around BDB JE issue by turning off the
coalescing committer and switching to a stricter durability policy
"SYNC,SYNC,SIMPLE_MAJORITY" or "SYNC,NO_SYNC,SIMPLE_MAJORITY".
If you were able to reproduce the reported issue with Qpid Broker 8.0.5 and
context qpid.bdb.ha.disable_coalescing_committer=true, I suppose you can try
changing further your durability to SYNC,SYNC,SIMPLE_MAJORITY. If that will not
help, than, the only resolution for the issue would a fix in BDB JE and
upgrade to newer version of BDB on Qpid side.
> [Broker-J] Introduce a switch to disable coalescing committer in BDB HA
> message store
> -
>
> Key: QPID-8500
> URL: https://issues.apache.org/jira/browse/QPID-8500
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.4, qpid-java-broker-7.1.12
>
>
> A BDB JE replication Feeder fails sporadically with errors like the one below
> {noformat}
> Halted log file reading at file 0x7472c8 offset 0x199d07
> offset(decimal)=1678599 prev=0x199cd5:
> entry=DEL_LN_TXtype=31,version=14)
> prev=0x199cd5
> size=44
> Next entry should be at 0x199d49
> com.sleepycat.je.EnvironmentFailureException: (JE 7.4.5) want to read
> 52,431,066,320 but reader at 52,431,066,327 UNEXPECTED_STATE: Unexpected
> internal state, may have side effects.
> at
> com.sleepycat.je.EnvironmentFailureException.unexpectedState(EnvironmentFailureException.java:428)
> at
> com.sleepycat.je.rep.stream.FeederReader.checkForPassingTarget(FeederReader.java:297)
> at
> com.sleepycat.je.rep.stream.FeederReader.isTargetEntry(FeederReader.java:317)
> at
> com.sleepycat.je.log.FileReader.readNextEntryAllowExceptions(FileReader.java:332)
> at com.sleepycat.je.log.FileReader.readNextEntry(FileReader.java:245)
> at
> com.sleepycat.je.rep.stream.FeederReader.scanForwards(FeederReader.java:280)
> at
> com.sleepycat.je.rep.stream.MasterFeederSource.getWireRecord(MasterFeederSource.java:70)
> at
> com.sleepycat.je.rep.impl.node.Feeder$OutputThread.writeAvailableEntries(Feeder.java:1266)
> at
> com.sleepycat.je.rep.impl.node.Feeder$OutputThread.run(Feeder.java:1144)
> {noformat}
> Based on discussion at
> [https://community.oracle.com/tech/developers/discussion/4300421/master-fails-unexpectedly-due-to-feeder-output-halted-log-file-reading-at-file-0x334f63-offset-0x8ce]
> we need a way to configure broker without a coalescing committer. The local
> sync policy would be set as per user virtual host settings.
> A context variable can be added into BDB HA to disable coalescing committer
> thread.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8556) [Broker-J] Expose virtual host threshold for triggering flow to disk on direct memory utilization
[
https://issues.apache.org/jira/browse/QPID-8556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8556:
-
Issue Type: Improvement (was: Bug)
> [Broker-J] Expose virtual host threshold for triggering flow to disk on
> direct memory utilization
> -
>
> Key: QPID-8556
> URL: https://issues.apache.org/jira/browse/QPID-8556
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.6
>
>
> The virtual host {{#TargetSize}} is used to trigger flow to disk, when
> direct memory utilization reaches {{#TargetSize}}. In order to improve
> Broker-J direct memory usage monitoring, the {{#TargetSize}} needs to be
> exposed as point in time statistics.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8546) [Broker-J] BDB HA replication of atomic BDB transactions for message acknowldgements impacts consumer performance
[ https://issues.apache.org/jira/browse/QPID-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8546: - Summary: [Broker-J] BDB HA replication of atomic BDB transactions for message acknowldgements impacts consumer performance (was: [Broker-J] Consumer falling behind producer in the BDB HA clusters) > [Broker-J] BDB HA replication of atomic BDB transactions for message > acknowldgements impacts consumer performance > - > > Key: QPID-8546 > URL: https://issues.apache.org/jira/browse/QPID-8546 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > > With current Qpid Broker versions (up to 8.0.4 including) when BDB HA cluster > is distributed across different DCs, a consumer throughput falls > significantly behind the producer . As result, the total system throughput > (determined by the consumer) can be very low. > Such behavior is caused by implementation specifics of BDB message store: > * BDB HA transactions are synchronous for the majority of the nodes. (The > messaging transaction is committed when majority of the nodes in the cluster > acknowledge the transaction on their side) > * The deletion of dequeued messages from the store is synchronous and > impacted by the DC latency. > * 2 separate underlying store transactions are used to delete each > individual message data. Thus, if message consumption happens in > transactional batches of N, the messages are dequeued from the queue in the > transacted batch of N messages. However, after message dequeuing, the > unreferenced message data is deleted using its own store transactions (one > for content and another for metadata). As result for a batch of N, the store > runs 1 + N*2 transactions. The N*2 transactions are synchronous and executed > one after another. If a latency between data centers is high, it adds a > corresponding delay to each store transaction. As result, the message removal > takes time. Only after deletion of N messages, the broker sends commit > confirmation to the client. The message enqueing works differently. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8561) [Broker-J] Release Qpid Broker-J 8.0.6
Alex Rudyy created QPID-8561: Summary: [Broker-J] Release Qpid Broker-J 8.0.6 Key: QPID-8561 URL: https://issues.apache.org/jira/browse/QPID-8561 Project: Qpid Issue Type: Task Components: Broker-J Reporter: Alex Rudyy Fix For: qpid-java-broker-8.0.6 Release Qpid Broker-J 8.0.6 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8530) [Broker-J] Duplicated functionality of the Selector::wakeup method in SelectorThread
[
https://issues.apache.org/jira/browse/QPID-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8530.
--
Resolution: Fixed
> [Broker-J] Duplicated functionality of the Selector::wakeup method in
> SelectorThread
>
>
> Key: QPID-8530
> URL: https://issues.apache.org/jira/browse/QPID-8530
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Marek Laca
>Priority: Minor
> Labels: Broker, Java, Thread, selector
> Fix For: qpid-java-broker-8.0.6
>
>
> It is stated in Java documentation of the
> [Selector::wakeup|https://docs.oracle.com/javase/7/docs/api/java/nio/channels/Selector.html#wakeup()]
> method that:
> {code:none}
> Causes the first selection operation that has not yet returned to return
> immediately.
> If another thread is currently blocked in an invocation of the select() or
> select(long) methods then that invocation will return immediately. If no
> selection operation is currently in progress then the next invocation of one
> of these methods will return immediately unless the selectNow() method is
> invoked in the meantime. In any case the value returned by that invocation
> may be non-zero. Subsequent invocations of the select() or select(long)
> methods will block as usual unless this method is invoked again in the
> meantime.
> Invoking this method more than once between two successive selection
> operations has the same effect as invoking it just once.
> {code}
> SelectorThread.SelectionTask inner class in Java broker duplicates build in
> functionality of the Selector::wakeup method, what complicates the
> implementation. If the class attributes '_inSelect' and '_wakeups' were
> removed then the code of SelectorThread.SelectionTask class would be
> simplified. The wakeup method could be directly executed, there is no need
> for another checks.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8560) [Broker-J] Upgrade fasterxml jackson dependency
[ https://issues.apache.org/jira/browse/QPID-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8560. -- Resolution: Fixed > [Broker-J] Upgrade fasterxml jackson dependency > --- > > Key: QPID-8560 > URL: https://issues.apache.org/jira/browse/QPID-8560 > Project: Qpid > Issue Type: Bug > Components: Broker-J > Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > > A new version of fasterxml jackson library has been released - 2.12.4. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8559) [Broker-J] Add debug logs for flow to disk events
[ https://issues.apache.org/jira/browse/QPID-8559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8559. -- Resolution: Fixed > [Broker-J] Add debug logs for flow to disk events > - > > Key: QPID-8559 > URL: https://issues.apache.org/jira/browse/QPID-8559 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > > The flow to disk functionality does not issue any logs on triggering flow to > disk. The debug level logs for flow to disk events could be very helpful for > investigation of OOM conditions caused by direct memory consumption. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8523) [Broker-J] refusing-attach while rejecting consumer does not set required initial-delivery-count field
[
https://issues.apache.org/jira/browse/QPID-8523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8523:
-
Fix Version/s: (was: qpid-java-broker-8.0.6)
qpid-java-broker-8.0.7
> [Broker-J] refusing-attach while rejecting consumer does not set required
> initial-delivery-count field
> --
>
> Key: QPID-8523
> URL: https://issues.apache.org/jira/browse/QPID-8523
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.4
>Reporter: Robbie Gemmell
>Priority: Major
> Fix For: qpid-java-broker-8.0.7
>
>
> Attempting to create a consumer link from e.g. a non-existing address results
> in refusal of the link, which in case of a consumer is done by sending a
> 'response' attach with null source to indicate the terminus wasnt created,
> followed by a detach with the error.
> The broker does send an attach without a source, but it omits the
> initialDeliveryCount value from the attach, which the spec says is required
> when role=SENDER ("This MUST NOT be null if role is sender, and it is ignored
> if the role is receiver."). Protocol libraries validating such required
> values will run afoul of this, leading to decode error that can bring the
> connection down unnecessarily.
> From looking at the wire encoding, it appears only the first 3 fields (name,
> handle, role) of the attach are being set, with the rest unpopulated and thus
> being equivalent to null or any default they may have.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8523) [Broker-J] refusing-attach while rejecting consumer does not set required initial-delivery-count field
[
https://issues.apache.org/jira/browse/QPID-8523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402864#comment-17402864
]
Alex Rudyy commented on QPID-8523:
--
The JIRA is de-scoped from version 8.0.6
> [Broker-J] refusing-attach while rejecting consumer does not set required
> initial-delivery-count field
> --
>
> Key: QPID-8523
> URL: https://issues.apache.org/jira/browse/QPID-8523
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.4
>Reporter: Robbie Gemmell
>Priority: Major
> Fix For: qpid-java-broker-8.0.7
>
>
> Attempting to create a consumer link from e.g. a non-existing address results
> in refusal of the link, which in case of a consumer is done by sending a
> 'response' attach with null source to indicate the terminus wasnt created,
> followed by a detach with the error.
> The broker does send an attach without a source, but it omits the
> initialDeliveryCount value from the attach, which the spec says is required
> when role=SENDER ("This MUST NOT be null if role is sender, and it is ignored
> if the role is receiver."). Protocol libraries validating such required
> values will run afoul of this, leading to decode error that can bring the
> connection down unnecessarily.
> From looking at the wire encoding, it appears only the first 3 fields (name,
> handle, role) of the attach are being set, with the rest unpopulated and thus
> being equivalent to null or any default they may have.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8530) [Broker-J] Duplicated functionality of the Selector::wakeup method in SelectorThread
[
https://issues.apache.org/jira/browse/QPID-8530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8530:
-
Fix Version/s: qpid-java-broker-8.0.6
> [Broker-J] Duplicated functionality of the Selector::wakeup method in
> SelectorThread
>
>
> Key: QPID-8530
> URL: https://issues.apache.org/jira/browse/QPID-8530
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Marek Laca
>Priority: Minor
> Labels: Broker, Java, Thread, selector
> Fix For: qpid-java-broker-8.0.6
>
>
> It is stated in Java documentation of the
> [Selector::wakeup|https://docs.oracle.com/javase/7/docs/api/java/nio/channels/Selector.html#wakeup()]
> method that:
> {code:none}
> Causes the first selection operation that has not yet returned to return
> immediately.
> If another thread is currently blocked in an invocation of the select() or
> select(long) methods then that invocation will return immediately. If no
> selection operation is currently in progress then the next invocation of one
> of these methods will return immediately unless the selectNow() method is
> invoked in the meantime. In any case the value returned by that invocation
> may be non-zero. Subsequent invocations of the select() or select(long)
> methods will block as usual unless this method is invoked again in the
> meantime.
> Invoking this method more than once between two successive selection
> operations has the same effect as invoking it just once.
> {code}
> SelectorThread.SelectionTask inner class in Java broker duplicates build in
> functionality of the Selector::wakeup method, what complicates the
> implementation. If the class attributes '_inSelect' and '_wakeups' were
> removed then the code of SelectorThread.SelectionTask class would be
> simplified. The wakeup method could be directly executed, there is no need
> for another checks.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8554) [Broker-J] Infinite loop in CachingSecurityToken class
[
https://issues.apache.org/jira/browse/QPID-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402861#comment-17402861
]
Alex Rudyy commented on QPID-8554:
--
Hi [~lacam],
Could you please provide more details on conditions when the reported issue
manifest?
IMHO, the loop should eventually ends after the updating the CACHE_UPDATE.
> [Broker-J] Infinite loop in CachingSecurityToken class
> --
>
> Key: QPID-8554
> URL: https://issues.apache.org/jira/browse/QPID-8554
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Marek Laca
>Priority: Minor
> Labels: Broker, Java, thread-safe
>
> The CachingSecurityToken class is caching the authorization results. It can
> be utilized by multiple threads at the same time. Hence, it has to be
> multi-thread safe. The CachingSecurityToken::authorise could get stuck in an
> infinite loop when multiple threads try to update the local cache
> simultaneously.
> Two threads can be in permanent conflict when each thread is trying to
> override changes of another thread.
> {code:java}
> AccessControlCache cache;
> while((cache = CACHE_UPDATE.get(this)).getAccessControl() !=
> ruleBasedAccessControl)
> {
> CACHE_UPDATE.compareAndSet(this, cache, new
> AccessControlCache(ruleBasedAccessControl));
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8550) [Broker-J] HP Fortify: Unreleased streams
[ https://issues.apache.org/jira/browse/QPID-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8550: - Fix Version/s: qpid-java-broker-9.0.0 > [Broker-J] HP Fortify: Unreleased streams > - > > Key: QPID-8550 > URL: https://issues.apache.org/jira/browse/QPID-8550 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Daniil Kirilyuk >Priority: Minor > Fix For: qpid-java-broker-9.0.0 > > > HP Fortify complains about several places where streams potentially do not > get released properly: > broker-core/src/main/java/org/apache/qpid/server/store/JsonFileConfigStore.java > The function load() in JsonFileConfigStore.java sometimes fails to release a > system resource allocated by FileReader() on line 162. > broker-core/src/main/java/org/org/apache/qpid/server/virtualhostnode/AbstractVirtualHostNode.java > The function getInitialRecords() in AbstractVirtualHostNode.java sometimes > fails to release a system resource allocated by ,[object Object], on line 435. > broker-plugins/management-http/src/main/java/org/apache/qpid/server/management/plugin/servlet.rest/RestServlet.java > The function parse() in RestServlet.java sometimes fails to release a system > resource allocated by getInputStream() on line 440. > tools/src/main/java/org/apache/qpid/tools/RestStressTestClient.java > The function put() in RestStressTestClient.java sometimes fails to release a > system resource allocated by getOutputStream() on line 318. > perftests/src/main/java/org/apache/qpid/disttest/controller/config/ConfigReader.java > The function getConfigFromFile() in ConfigReader.java sometimes fails to > release a system resource allocated by getConfigReader() on line 40. > perftests/src/main/java/org/apache/qpid/disttest/controller/config/JavaScriptConfigEvaluator.java > The function evaluateJavaScript() in JavaScriptConfigEvaluator.java sometimes > fails to release a system resource allocated by InputStreamReader() on line > 70. > The function evaluateJavaScript() in JavaScriptConfigEvaluator.java sometimes > fails to release a system resource allocated by InputStreamReader() on line > 71. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8550) [Broker-J] HP Fortify: Unreleased streams
[ https://issues.apache.org/jira/browse/QPID-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8550. -- Resolution: Fixed > [Broker-J] HP Fortify: Unreleased streams > - > > Key: QPID-8550 > URL: https://issues.apache.org/jira/browse/QPID-8550 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Daniil Kirilyuk >Priority: Minor > Fix For: qpid-java-broker-9.0.0 > > > HP Fortify complains about several places where streams potentially do not > get released properly: > broker-core/src/main/java/org/apache/qpid/server/store/JsonFileConfigStore.java > The function load() in JsonFileConfigStore.java sometimes fails to release a > system resource allocated by FileReader() on line 162. > broker-core/src/main/java/org/org/apache/qpid/server/virtualhostnode/AbstractVirtualHostNode.java > The function getInitialRecords() in AbstractVirtualHostNode.java sometimes > fails to release a system resource allocated by ,[object Object], on line 435. > broker-plugins/management-http/src/main/java/org/apache/qpid/server/management/plugin/servlet.rest/RestServlet.java > The function parse() in RestServlet.java sometimes fails to release a system > resource allocated by getInputStream() on line 440. > tools/src/main/java/org/apache/qpid/tools/RestStressTestClient.java > The function put() in RestStressTestClient.java sometimes fails to release a > system resource allocated by getOutputStream() on line 318. > perftests/src/main/java/org/apache/qpid/disttest/controller/config/ConfigReader.java > The function getConfigFromFile() in ConfigReader.java sometimes fails to > release a system resource allocated by getConfigReader() on line 40. > perftests/src/main/java/org/apache/qpid/disttest/controller/config/JavaScriptConfigEvaluator.java > The function evaluateJavaScript() in JavaScriptConfigEvaluator.java sometimes > fails to release a system resource allocated by InputStreamReader() on line > 70. > The function evaluateJavaScript() in JavaScriptConfigEvaluator.java sometimes > fails to release a system resource allocated by InputStreamReader() on line > 71. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8560) [Broker-J] Upgrade fasterxml jackson dependency
Alex Rudyy created QPID-8560: Summary: [Broker-J] Upgrade fasterxml jackson dependency Key: QPID-8560 URL: https://issues.apache.org/jira/browse/QPID-8560 Project: Qpid Issue Type: Bug Components: Broker-J Reporter: Alex Rudyy Fix For: qpid-java-broker-8.0.6 A new version of fasterxml jackson library has been released - 2.12.4. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8559) [Broker-J] Add debug logs for flow to disk events
[ https://issues.apache.org/jira/browse/QPID-8559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8559: - Component/s: Broker-J > [Broker-J] Add debug logs for flow to disk events > - > > Key: QPID-8559 > URL: https://issues.apache.org/jira/browse/QPID-8559 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > > The flow to disk functionality does not issue any logs on triggering flow to > disk. The debug level logs for flow to disk events could be very helpful for > investigation of OOM conditions caused by direct memory consumption. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8559) [Broker-J] Add debug logs for flow to disk events
[ https://issues.apache.org/jira/browse/QPID-8559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8559: - Description: The flow to disk functionality does not issue any logs on triggering flow to disk. The debug level logs for flow to disk events could be very helpful for investigation of OOM conditions caused by direct memory consumption. (was: The debug logs ) > [Broker-J] Add debug logs for flow to disk events > - > > Key: QPID-8559 > URL: https://issues.apache.org/jira/browse/QPID-8559 > Project: Qpid > Issue Type: Improvement > Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > > The flow to disk functionality does not issue any logs on triggering flow to > disk. The debug level logs for flow to disk events could be very helpful for > investigation of OOM conditions caused by direct memory consumption. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8559) [Broker-J] Add debug logs for flow to disk events
[ https://issues.apache.org/jira/browse/QPID-8559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8559: - Fix Version/s: qpid-java-broker-8.0.6 > [Broker-J] Add debug logs for flow to disk events > - > > Key: QPID-8559 > URL: https://issues.apache.org/jira/browse/QPID-8559 > Project: Qpid > Issue Type: Improvement > Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8559) [Broker-J] Add debug logs for flow to disk events
[ https://issues.apache.org/jira/browse/QPID-8559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8559: - Description: The debug logs > [Broker-J] Add debug logs for flow to disk events > - > > Key: QPID-8559 > URL: https://issues.apache.org/jira/browse/QPID-8559 > Project: Qpid > Issue Type: Improvement > Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > > The debug logs -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8559) [Broker-J] Add debug logs for flow to disk events
[ https://issues.apache.org/jira/browse/QPID-8559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8559: - Issue Type: Improvement (was: Bug) > [Broker-J] Add debug logs for flow to disk events > - > > Key: QPID-8559 > URL: https://issues.apache.org/jira/browse/QPID-8559 > Project: Qpid > Issue Type: Improvement > Reporter: Alex Rudyy >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8559) [Broker-J] Add debug logs for flow to disk events
[ https://issues.apache.org/jira/browse/QPID-8559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8559: - Summary: [Broker-J] Add debug logs for flow to disk events (was: [) > [Broker-J] Add debug logs for flow to disk events > - > > Key: QPID-8559 > URL: https://issues.apache.org/jira/browse/QPID-8559 > Project: Qpid > Issue Type: Bug > Reporter: Alex Rudyy >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8559) [
Alex Rudyy created QPID-8559: Summary: [ Key: QPID-8559 URL: https://issues.apache.org/jira/browse/QPID-8559 Project: Qpid Issue Type: Bug Reporter: Alex Rudyy -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8545) [Broker-J] SSL Engine looping circuit breaker
[ https://issues.apache.org/jira/browse/QPID-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8545. -- Resolution: Fixed > [Broker-J] SSL Engine looping circuit breaker > - > > Key: QPID-8545 > URL: https://issues.apache.org/jira/browse/QPID-8545 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Daniil Kirilyuk >Priority: Minor > Fix For: qpid-java-broker-9.0.0 > > > A configurable circuit breaker should be added to > NonBlockingConnectionTLSDelegate giving the possibility to stop SSL engine > looping (QPID-8526, QPID-8489). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8546) [Broker-J] Consumer falling behind producer in the BDB HA clusters
[ https://issues.apache.org/jira/browse/QPID-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8546: - Fix Version/s: qpid-java-broker-8.0.6 > [Broker-J] Consumer falling behind producer in the BDB HA clusters > -- > > Key: QPID-8546 > URL: https://issues.apache.org/jira/browse/QPID-8546 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > > With current Qpid Broker versions (up to 8.0.4 including) when BDB HA cluster > is distributed across different DCs, a consumer throughput falls > significantly behind the producer . As result, the total system throughput > (determined by the consumer) can be very low. > Such behavior is caused by implementation specifics of BDB message store: > * BDB HA transactions are synchronous for the majority of the nodes. (The > messaging transaction is committed when majority of the nodes in the cluster > acknowledge the transaction on their side) > * The deletion of dequeued messages from the store is synchronous and > impacted by the DC latency. > * 2 separate underlying store transactions are used to delete each > individual message data. Thus, if message consumption happens in > transactional batches of N, the messages are dequeued from the queue in the > transacted batch of N messages. However, after message dequeuing, the > unreferenced message data is deleted using its own store transactions (one > for content and another for metadata). As result for a batch of N, the store > runs 1 + N*2 transactions. The N*2 transactions are synchronous and executed > one after another. If a latency between data centers is high, it adds a > corresponding delay to each store transaction. As result, the message removal > takes time. Only after deletion of N messages, the broker sends commit > confirmation to the client. The message enqueing works differently. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8545) [Broker-J] SSL Engine looping circuit breaker
[ https://issues.apache.org/jira/browse/QPID-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8545: - Fix Version/s: qpid-java-broker-9.0.0 > [Broker-J] SSL Engine looping circuit breaker > - > > Key: QPID-8545 > URL: https://issues.apache.org/jira/browse/QPID-8545 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Daniil Kirilyuk >Priority: Minor > Fix For: qpid-java-broker-9.0.0 > > > A configurable circuit breaker should be added to > NonBlockingConnectionTLSDelegate giving the possibility to stop SSL engine > looping (QPID-8526, QPID-8489). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8546) [Broker-J] Consumer falling behind producer in the BDB HA clusters
[ https://issues.apache.org/jira/browse/QPID-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8546: - Summary: [Broker-J] Consumer falling behind producer in the BDB HA clusters (was: Consumer falling behind producer in the BDB HA clusters) > [Broker-J] Consumer falling behind producer in the BDB HA clusters > -- > > Key: QPID-8546 > URL: https://issues.apache.org/jira/browse/QPID-8546 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Dedeepya >Priority: Major > > With current Qpid Broker versions (up to 8.0.4 including) when BDB HA cluster > is distributed across different DCs, a consumer throughput falls > significantly behind the producer . As result, the total system throughput > (determined by the consumer) can be very low. > Such behavior is caused by implementation specifics of BDB message store: > * BDB HA transactions are synchronous for the majority of the nodes. (The > messaging transaction is committed when majority of the nodes in the cluster > acknowledge the transaction on their side) > * The deletion of dequeued messages from the store is synchronous and > impacted by the DC latency. > * 2 separate underlying store transactions are used to delete each > individual message data. Thus, if message consumption happens in > transactional batches of N, the messages are dequeued from the queue in the > transacted batch of N messages. However, after message dequeuing, the > unreferenced message data is deleted using its own store transactions (one > for content and another for metadata). As result for a batch of N, the store > runs 1 + N*2 transactions. The N*2 transactions are synchronous and executed > one after another. If a latency between data centers is high, it adds a > corresponding delay to each store transaction. As result, the message removal > takes time. Only after deletion of N messages, the broker sends commit > confirmation to the client. The message enqueing works differently. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8546) [Broker-J] Consumer falling behind producer in the BDB HA clusters
[ https://issues.apache.org/jira/browse/QPID-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8546. -- Resolution: Fixed > [Broker-J] Consumer falling behind producer in the BDB HA clusters > -- > > Key: QPID-8546 > URL: https://issues.apache.org/jira/browse/QPID-8546 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > > With current Qpid Broker versions (up to 8.0.4 including) when BDB HA cluster > is distributed across different DCs, a consumer throughput falls > significantly behind the producer . As result, the total system throughput > (determined by the consumer) can be very low. > Such behavior is caused by implementation specifics of BDB message store: > * BDB HA transactions are synchronous for the majority of the nodes. (The > messaging transaction is committed when majority of the nodes in the cluster > acknowledge the transaction on their side) > * The deletion of dequeued messages from the store is synchronous and > impacted by the DC latency. > * 2 separate underlying store transactions are used to delete each > individual message data. Thus, if message consumption happens in > transactional batches of N, the messages are dequeued from the queue in the > transacted batch of N messages. However, after message dequeuing, the > unreferenced message data is deleted using its own store transactions (one > for content and another for metadata). As result for a batch of N, the store > runs 1 + N*2 transactions. The N*2 transactions are synchronous and executed > one after another. If a latency between data centers is high, it adds a > corresponding delay to each store transaction. As result, the message removal > takes time. Only after deletion of N messages, the broker sends commit > confirmation to the client. The message enqueing works differently. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8500) [Broker-J] Introduce a switch to disable coalescing committer in BDB HA message store
[
https://issues.apache.org/jira/browse/QPID-8500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17395664#comment-17395664
]
Alex Rudyy commented on QPID-8500:
--
Hi [~1025524...@qq.com],
The stack trace indicates that message acknowledgement happened on node
transition into unknown state. The node transition into an UNKNOWN state is a
different problem then the one which was addressed as part of this JIRA.
> [Broker-J] Introduce a switch to disable coalescing committer in BDB HA
> message store
> -
>
> Key: QPID-8500
> URL: https://issues.apache.org/jira/browse/QPID-8500
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.4, qpid-java-broker-7.1.12
>
>
> A BDB JE replication Feeder fails sporadically with errors like the one below
> {noformat}
> Halted log file reading at file 0x7472c8 offset 0x199d07
> offset(decimal)=1678599 prev=0x199cd5:
> entry=DEL_LN_TXtype=31,version=14)
> prev=0x199cd5
> size=44
> Next entry should be at 0x199d49
> com.sleepycat.je.EnvironmentFailureException: (JE 7.4.5) want to read
> 52,431,066,320 but reader at 52,431,066,327 UNEXPECTED_STATE: Unexpected
> internal state, may have side effects.
> at
> com.sleepycat.je.EnvironmentFailureException.unexpectedState(EnvironmentFailureException.java:428)
> at
> com.sleepycat.je.rep.stream.FeederReader.checkForPassingTarget(FeederReader.java:297)
> at
> com.sleepycat.je.rep.stream.FeederReader.isTargetEntry(FeederReader.java:317)
> at
> com.sleepycat.je.log.FileReader.readNextEntryAllowExceptions(FileReader.java:332)
> at com.sleepycat.je.log.FileReader.readNextEntry(FileReader.java:245)
> at
> com.sleepycat.je.rep.stream.FeederReader.scanForwards(FeederReader.java:280)
> at
> com.sleepycat.je.rep.stream.MasterFeederSource.getWireRecord(MasterFeederSource.java:70)
> at
> com.sleepycat.je.rep.impl.node.Feeder$OutputThread.writeAvailableEntries(Feeder.java:1266)
> at
> com.sleepycat.je.rep.impl.node.Feeder$OutputThread.run(Feeder.java:1144)
> {noformat}
> Based on discussion at
> [https://community.oracle.com/tech/developers/discussion/4300421/master-fails-unexpectedly-due-to-feeder-output-halted-log-file-reading-at-file-0x334f63-offset-0x8ce]
> we need a way to configure broker without a coalescing committer. The local
> sync policy would be set as per user virtual host settings.
> A context variable can be added into BDB HA to disable coalescing committer
> thread.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8500) [Broker-J] Introduce a switch to disable coalescing committer in BDB HA message store
[
https://issues.apache.org/jira/browse/QPID-8500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17393724#comment-17393724
]
Alex Rudyy commented on QPID-8500:
--
Hi [~1025524...@qq.com],
I was hoping that running BDB JE HA without coalescing committer and durability
SYN,SYN,MAJORITY would help to workaround the reported issue with BDB JE
replication.
Thus, a special context variable was introduced to disabled the coalescing
committer.
Could you please confirm that you managed to reproduce the problem when
{{qpid.bdb.ha.disable_coalescing_committer}} was set to {{true}}?
> [Broker-J] Introduce a switch to disable coalescing committer in BDB HA
> message store
> -
>
> Key: QPID-8500
> URL: https://issues.apache.org/jira/browse/QPID-8500
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.4, qpid-java-broker-7.1.12
>
>
> A BDB JE replication Feeder fails sporadically with errors like the one below
> {noformat}
> Halted log file reading at file 0x7472c8 offset 0x199d07
> offset(decimal)=1678599 prev=0x199cd5:
> entry=DEL_LN_TXtype=31,version=14)
> prev=0x199cd5
> size=44
> Next entry should be at 0x199d49
> com.sleepycat.je.EnvironmentFailureException: (JE 7.4.5) want to read
> 52,431,066,320 but reader at 52,431,066,327 UNEXPECTED_STATE: Unexpected
> internal state, may have side effects.
> at
> com.sleepycat.je.EnvironmentFailureException.unexpectedState(EnvironmentFailureException.java:428)
> at
> com.sleepycat.je.rep.stream.FeederReader.checkForPassingTarget(FeederReader.java:297)
> at
> com.sleepycat.je.rep.stream.FeederReader.isTargetEntry(FeederReader.java:317)
> at
> com.sleepycat.je.log.FileReader.readNextEntryAllowExceptions(FileReader.java:332)
> at com.sleepycat.je.log.FileReader.readNextEntry(FileReader.java:245)
> at
> com.sleepycat.je.rep.stream.FeederReader.scanForwards(FeederReader.java:280)
> at
> com.sleepycat.je.rep.stream.MasterFeederSource.getWireRecord(MasterFeederSource.java:70)
> at
> com.sleepycat.je.rep.impl.node.Feeder$OutputThread.writeAvailableEntries(Feeder.java:1266)
> at
> com.sleepycat.je.rep.impl.node.Feeder$OutputThread.run(Feeder.java:1144)
> {noformat}
> Based on discussion at
> [https://community.oracle.com/tech/developers/discussion/4300421/master-fails-unexpectedly-due-to-feeder-output-halted-log-file-reading-at-file-0x334f63-offset-0x8ce]
> we need a way to configure broker without a coalescing committer. The local
> sync policy would be set as per user virtual host settings.
> A context variable can be added into BDB HA to disable coalescing committer
> thread.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8484) [Broker-J] Reimplementation of the limit number of connections per user
[ https://issues.apache.org/jira/browse/QPID-8484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8484. -- Resolution: Fixed > [Broker-J] Reimplementation of the limit number of connections per user > --- > > Key: QPID-8484 > URL: https://issues.apache.org/jira/browse/QPID-8484 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.1, qpid-java-broker-8.0.2 >Reporter: Marek Laca >Priority: Major > Labels: connection, limit, user > Fix For: qpid-java-broker-9.0.0 > > > If some user creates too much connections, he can prevent other users from > connecting to amqp ports. > [QPID-8369|https://issues.apache.org/jira/projects/QPID/issues/QPID-8369] > added an ability to limit maximum open connections per user. > The user connection limit was implemented as ACL dynamic rule and it is part > of the access control logic. > But I have queries about the implementation: > * The connection count of the user is not checked properly. > For example 2 connections should be rejected when an user has limit 5 and > tries to open 7 parallel connections. But what happens: > ## Every connection increments the counter then the counter will be 7. > ## ACL logic compares the actual counter value with the limit for every > connection (the counter value at the moment of the acl rule check) and 2,3 … > or all 7 connections can be denied. The ACL logic does not know which > connection broke the limit. > ## The counter is decremented when connection is closed. > * ACL rules were static and so the result of the check did not vary in time > and the Broker could cache the result ALLOWED or DENIED. From my point of > view a dynamic check should not be part of the ACL logic because it makes ACL > logic time dependent. > * The user connection limit should be checked as soon as possible. > I suggest to introduce a new plugin (similar to the access control provider > plugin) that will hold the user's counters of open connections. > It will provide following functionality: > * It registers new connections for given user and the connection will be > rejected if the user breaks the limit. The registration and update of user's > counters will be an atomic operation. > * It de-registers the connections for given user. > If user breaks the limit then the connection will be closed with proper > response "amqp:resource-limit-exceeded" instead of "amqp:not-allowed". -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8484) [Broker-J] Reimplementation of the limit number of connections per user
[ https://issues.apache.org/jira/browse/QPID-8484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8484: - Fix Version/s: qpid-java-broker-9.0.0 > [Broker-J] Reimplementation of the limit number of connections per user > --- > > Key: QPID-8484 > URL: https://issues.apache.org/jira/browse/QPID-8484 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.1, qpid-java-broker-8.0.2 >Reporter: Marek Laca >Priority: Major > Labels: connection, limit, user > Fix For: qpid-java-broker-9.0.0 > > > If some user creates too much connections, he can prevent other users from > connecting to amqp ports. > [QPID-8369|https://issues.apache.org/jira/projects/QPID/issues/QPID-8369] > added an ability to limit maximum open connections per user. > The user connection limit was implemented as ACL dynamic rule and it is part > of the access control logic. > But I have queries about the implementation: > * The connection count of the user is not checked properly. > For example 2 connections should be rejected when an user has limit 5 and > tries to open 7 parallel connections. But what happens: > ## Every connection increments the counter then the counter will be 7. > ## ACL logic compares the actual counter value with the limit for every > connection (the counter value at the moment of the acl rule check) and 2,3 … > or all 7 connections can be denied. The ACL logic does not know which > connection broke the limit. > ## The counter is decremented when connection is closed. > * ACL rules were static and so the result of the check did not vary in time > and the Broker could cache the result ALLOWED or DENIED. From my point of > view a dynamic check should not be part of the ACL logic because it makes ACL > logic time dependent. > * The user connection limit should be checked as soon as possible. > I suggest to introduce a new plugin (similar to the access control provider > plugin) that will hold the user's counters of open connections. > It will provide following functionality: > * It registers new connections for given user and the connection will be > rejected if the user breaks the limit. The registration and update of user's > counters will be an atomic operation. > * It de-registers the connections for given user. > If user breaks the limit then the connection will be closed with proper > response "amqp:resource-limit-exceeded" instead of "amqp:not-allowed". -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8556) [Broker-J] Expose virtual host threshold for triggering flow to disk on direct memory utilization
[
https://issues.apache.org/jira/browse/QPID-8556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8556.
--
Resolution: Fixed
> [Broker-J] Expose virtual host threshold for triggering flow to disk on
> direct memory utilization
> -
>
> Key: QPID-8556
> URL: https://issues.apache.org/jira/browse/QPID-8556
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.6
>
>
> The virtual host {{#TargetSize}} is used to trigger flow to disk, when
> direct memory utilization reaches {{#TargetSize}}. In order to improve
> Broker-J direct memory usage monitoring, the {{#TargetSize}} needs to be
> exposed as point in time statistics.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8549) [Broker-J] HP Fortify: Null de-reference
[ https://issues.apache.org/jira/browse/QPID-8549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8549. -- Resolution: Fixed > [Broker-J] HP Fortify: Null de-reference > > > Key: QPID-8549 > URL: https://issues.apache.org/jira/browse/QPID-8549 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Daniil Kirilyuk >Priority: Minor > Fix For: qpid-java-broker-9.0.0 > > > HP Fortify complains about several places where a null might get > de-referenced: > broker-core/src/main/java/org/apache/qpid/server/transport/MultiVersionProtocolEngine.java > 467 - Assigned null : supportedReplyVersion > Can be refactored to String.valueOf() > 469 - Dereferenced : supportedReplyBytes > broker-plugins/amqp-1-0-protocol/src/main/java/org/apache/qpid/server/protocol/v1_0/AMQPConnection_1_0Impl.java > 957 - Dereferenced : soleConnectionEnforcementPolicy > 968 - Dereferenced : soleConnectionEnforcementPolicy > broker-core/src/main/java/org/apache/qpid/server/consumer/AbstractConsumerTarget.java > 282 - Dereferenced : consumer > broker-core/src/main/java/org/apache/qpid/server/queue/SortedQueueEntryList.java > 113 - Dereferenced : parent > 122 - Dereferenced : parent > tools/src/main/java/org/apache/qpid/tools/StressTestClient.java > 409 - Dereferenced : consumer > tools/src/main/java/org/apache/qpid/tools/util/ArgumentsParser.java > 166 - Dereferenced : defaultValue > broker-plugins/amqp-1-0-protocol/src/main/org/apache/qpid/server/protocol/v1_0/ConsumerTarget_1_0.java > 489 - Dereferenced : txn > 508 - Dereferenced : txn > 536 - Dereferenced : txn > 557 - Dereferenced : txn > 592 - Dereferenced : txn > bdbstore/src/main/java/org/apache/qpid/server/store/berkeleydb/BDBConfiguredObjectRecord.java > 114 - Dereferenced : > broker-plugins/amqp-1-0-protocol/src/main/java/org/apache/qpid/server/protocol/v1_0/MessageConverter_from_1_0.java > 92 - Dereferenced : sections > broker-core/src/main/java/org/apache/qpid/server/queue/DefinedGroupMessageGroupManager.java > 259 - Dereferenced : messageHeader > 260 - Dereferenced : messageHeader -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8549) [Broker-J] HP Fortify: Null de-reference
[ https://issues.apache.org/jira/browse/QPID-8549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8549: - Fix Version/s: qpid-java-broker-9.0.0 > [Broker-J] HP Fortify: Null de-reference > > > Key: QPID-8549 > URL: https://issues.apache.org/jira/browse/QPID-8549 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Daniil Kirilyuk >Priority: Minor > Fix For: qpid-java-broker-9.0.0 > > > HP Fortify complains about several places where a null might get > de-referenced: > broker-core/src/main/java/org/apache/qpid/server/transport/MultiVersionProtocolEngine.java > 467 - Assigned null : supportedReplyVersion > Can be refactored to String.valueOf() > 469 - Dereferenced : supportedReplyBytes > broker-plugins/amqp-1-0-protocol/src/main/java/org/apache/qpid/server/protocol/v1_0/AMQPConnection_1_0Impl.java > 957 - Dereferenced : soleConnectionEnforcementPolicy > 968 - Dereferenced : soleConnectionEnforcementPolicy > broker-core/src/main/java/org/apache/qpid/server/consumer/AbstractConsumerTarget.java > 282 - Dereferenced : consumer > broker-core/src/main/java/org/apache/qpid/server/queue/SortedQueueEntryList.java > 113 - Dereferenced : parent > 122 - Dereferenced : parent > tools/src/main/java/org/apache/qpid/tools/StressTestClient.java > 409 - Dereferenced : consumer > tools/src/main/java/org/apache/qpid/tools/util/ArgumentsParser.java > 166 - Dereferenced : defaultValue > broker-plugins/amqp-1-0-protocol/src/main/org/apache/qpid/server/protocol/v1_0/ConsumerTarget_1_0.java > 489 - Dereferenced : txn > 508 - Dereferenced : txn > 536 - Dereferenced : txn > 557 - Dereferenced : txn > 592 - Dereferenced : txn > bdbstore/src/main/java/org/apache/qpid/server/store/berkeleydb/BDBConfiguredObjectRecord.java > 114 - Dereferenced : > broker-plugins/amqp-1-0-protocol/src/main/java/org/apache/qpid/server/protocol/v1_0/MessageConverter_from_1_0.java > 92 - Dereferenced : sections > broker-core/src/main/java/org/apache/qpid/server/queue/DefinedGroupMessageGroupManager.java > 259 - Dereferenced : messageHeader > 260 - Dereferenced : messageHeader -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8553) [Broker-J] HP Fortify: Weak SecurityManager Check: Overridable Method
[ https://issues.apache.org/jira/browse/QPID-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8553: - Summary: [Broker-J] HP Fortify: Weak SecurityManager Check: Overridable Method (was: [Broker-J] Improve NPE checks) > [Broker-J] HP Fortify: Weak SecurityManager Check: Overridable Method > - > > Key: QPID-8553 > URL: https://issues.apache.org/jira/browse/QPID-8553 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Daniil Kirilyuk >Priority: Minor > Fix For: qpid-java-broker-9.0.0 > > > HP Fortify complains that classes defining security may be overridden by > sub-classes and thereby by-passing the security features: > broker-plugins/access-control/src/main/org/apache/qpid/server/security/access/config/RuleBasedAccessControl.java > Line 58 newToken() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 75 authorise() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-core/src/main/java/org/apache/qpid/server/model/BrokerImpl.java > Line 1022 getConnectionMetaData() - Non-final methods that perform security > checks may be overridden in ways that bypass security checks. > Line 1046 getGroups() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/management-http/src/main/org/apache/qpid/server/management/plugin/servlet/rest/SaslServlet.java > Line 79 doGet() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/org/apache/qpid/server/protocol/v0_8/AMQPConnection_0_8Impl.java > Line 699 readerIdle() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/logging-logback/src/main/org/apache/qpid/server/logging/logback/ConnectionAndUserPredicate.java > Line 43 evaluate() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-1-0-protocol/src/main/org/apache/qpid/server/protocol/v1_0/AMQPConnection_1_0Impl.java > Line 444 receive() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 1269 readerIdle() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > Line 1340 receivedComplete() - Non-final methods that perform security checks > may be overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/src/main/org/apache/qpid/server/protocol/v0_8/BrokerDecoder.java > Line 78 processAMQPFrames() - Non-final methods that perform security checks > may be overridden in ways that bypass security checks. > Executes privileged action. > broker-core/src/main/java/org/apache/qpid/server/security/CompoundAccessControl.java > Line 68 newToken() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-10-protocol/src/main/java/org/apache/qpid/server/protocol/v0_10/ServerAssembler.java > Line 72 received() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/amqp-0-10-protocol/src/main/java/org/apache/qpid/server/protocol/v0_10/AMQPConnection_0_10Impl.java > Line 165 readerIdle() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 182 closed() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/management-amqp/src/main/java/org/apache/qpid/server/management/amqp/ProxyMessageSource.java > Line 152 addConsumer() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > broker-plugins/management-amqp/src/main/java/org/apache/qpid/server/management/amqp/ManagementAddressSpace.java > Line 172 getProxyNode() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > broker-plugins/logging-logback/src/main/java/org/apache/qpid/server/logging/logback/PrincipalLogEventFilter.java > Line 43 decide() - Non-final methods that perform security checks may be > overridden in ways that bypa
[jira] [Reopened] (QPID-8553) [Broker-J] HP Fortify: Weak SecurityManager Check: Overridable Method
[ https://issues.apache.org/jira/browse/QPID-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reopened QPID-8553: -- > [Broker-J] HP Fortify: Weak SecurityManager Check: Overridable Method > - > > Key: QPID-8553 > URL: https://issues.apache.org/jira/browse/QPID-8553 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Daniil Kirilyuk >Priority: Minor > Fix For: qpid-java-broker-9.0.0 > > > HP Fortify complains that classes defining security may be overridden by > sub-classes and thereby by-passing the security features: > broker-plugins/access-control/src/main/org/apache/qpid/server/security/access/config/RuleBasedAccessControl.java > Line 58 newToken() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 75 authorise() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-core/src/main/java/org/apache/qpid/server/model/BrokerImpl.java > Line 1022 getConnectionMetaData() - Non-final methods that perform security > checks may be overridden in ways that bypass security checks. > Line 1046 getGroups() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/management-http/src/main/org/apache/qpid/server/management/plugin/servlet/rest/SaslServlet.java > Line 79 doGet() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/org/apache/qpid/server/protocol/v0_8/AMQPConnection_0_8Impl.java > Line 699 readerIdle() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/logging-logback/src/main/org/apache/qpid/server/logging/logback/ConnectionAndUserPredicate.java > Line 43 evaluate() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-1-0-protocol/src/main/org/apache/qpid/server/protocol/v1_0/AMQPConnection_1_0Impl.java > Line 444 receive() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 1269 readerIdle() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > Line 1340 receivedComplete() - Non-final methods that perform security checks > may be overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/src/main/org/apache/qpid/server/protocol/v0_8/BrokerDecoder.java > Line 78 processAMQPFrames() - Non-final methods that perform security checks > may be overridden in ways that bypass security checks. > Executes privileged action. > broker-core/src/main/java/org/apache/qpid/server/security/CompoundAccessControl.java > Line 68 newToken() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-10-protocol/src/main/java/org/apache/qpid/server/protocol/v0_10/ServerAssembler.java > Line 72 received() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/amqp-0-10-protocol/src/main/java/org/apache/qpid/server/protocol/v0_10/AMQPConnection_0_10Impl.java > Line 165 readerIdle() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 182 closed() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/management-amqp/src/main/java/org/apache/qpid/server/management/amqp/ProxyMessageSource.java > Line 152 addConsumer() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > broker-plugins/management-amqp/src/main/java/org/apache/qpid/server/management/amqp/ManagementAddressSpace.java > Line 172 getProxyNode() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > broker-plugins/logging-logback/src/main/java/org/apache/qpid/server/logging/logback/PrincipalLogEventFilter.java > Line 43 decide() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/src/main/java/org/apache/qpid/server/protocol/v0_8
[jira] [Resolved] (QPID-8553) [Broker-J] Improve NPE checks
[ https://issues.apache.org/jira/browse/QPID-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8553. -- Resolution: Fixed > [Broker-J] Improve NPE checks > - > > Key: QPID-8553 > URL: https://issues.apache.org/jira/browse/QPID-8553 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Daniil Kirilyuk >Priority: Minor > Fix For: qpid-java-broker-9.0.0 > > > HP Fortify complains that classes defining security may be overridden by > sub-classes and thereby by-passing the security features: > broker-plugins/access-control/src/main/org/apache/qpid/server/security/access/config/RuleBasedAccessControl.java > Line 58 newToken() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 75 authorise() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-core/src/main/java/org/apache/qpid/server/model/BrokerImpl.java > Line 1022 getConnectionMetaData() - Non-final methods that perform security > checks may be overridden in ways that bypass security checks. > Line 1046 getGroups() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/management-http/src/main/org/apache/qpid/server/management/plugin/servlet/rest/SaslServlet.java > Line 79 doGet() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/org/apache/qpid/server/protocol/v0_8/AMQPConnection_0_8Impl.java > Line 699 readerIdle() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/logging-logback/src/main/org/apache/qpid/server/logging/logback/ConnectionAndUserPredicate.java > Line 43 evaluate() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-1-0-protocol/src/main/org/apache/qpid/server/protocol/v1_0/AMQPConnection_1_0Impl.java > Line 444 receive() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 1269 readerIdle() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > Line 1340 receivedComplete() - Non-final methods that perform security checks > may be overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/src/main/org/apache/qpid/server/protocol/v0_8/BrokerDecoder.java > Line 78 processAMQPFrames() - Non-final methods that perform security checks > may be overridden in ways that bypass security checks. > Executes privileged action. > broker-core/src/main/java/org/apache/qpid/server/security/CompoundAccessControl.java > Line 68 newToken() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-10-protocol/src/main/java/org/apache/qpid/server/protocol/v0_10/ServerAssembler.java > Line 72 received() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/amqp-0-10-protocol/src/main/java/org/apache/qpid/server/protocol/v0_10/AMQPConnection_0_10Impl.java > Line 165 readerIdle() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 182 closed() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/management-amqp/src/main/java/org/apache/qpid/server/management/amqp/ProxyMessageSource.java > Line 152 addConsumer() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > broker-plugins/management-amqp/src/main/java/org/apache/qpid/server/management/amqp/ManagementAddressSpace.java > Line 172 getProxyNode() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > broker-plugins/logging-logback/src/main/java/org/apache/qpid/server/logging/logback/PrincipalLogEventFilter.java > Line 43 decide() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/src/main/java/org/apache/qpid/server/protocol/v0_8/AMQChannel.java > Line 303 receivedComplete() - Non-final methods th
[jira] [Updated] (QPID-8553) [Broker-J] Improve NPE checks
[ https://issues.apache.org/jira/browse/QPID-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8553: - Fix Version/s: qpid-java-broker-9.0.0 > [Broker-J] Improve NPE checks > - > > Key: QPID-8553 > URL: https://issues.apache.org/jira/browse/QPID-8553 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Daniil Kirilyuk >Priority: Minor > Fix For: qpid-java-broker-9.0.0 > > > HP Fortify complains that classes defining security may be overridden by > sub-classes and thereby by-passing the security features: > broker-plugins/access-control/src/main/org/apache/qpid/server/security/access/config/RuleBasedAccessControl.java > Line 58 newToken() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 75 authorise() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-core/src/main/java/org/apache/qpid/server/model/BrokerImpl.java > Line 1022 getConnectionMetaData() - Non-final methods that perform security > checks may be overridden in ways that bypass security checks. > Line 1046 getGroups() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/management-http/src/main/org/apache/qpid/server/management/plugin/servlet/rest/SaslServlet.java > Line 79 doGet() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/org/apache/qpid/server/protocol/v0_8/AMQPConnection_0_8Impl.java > Line 699 readerIdle() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/logging-logback/src/main/org/apache/qpid/server/logging/logback/ConnectionAndUserPredicate.java > Line 43 evaluate() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-1-0-protocol/src/main/org/apache/qpid/server/protocol/v1_0/AMQPConnection_1_0Impl.java > Line 444 receive() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 1269 readerIdle() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > Line 1340 receivedComplete() - Non-final methods that perform security checks > may be overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/src/main/org/apache/qpid/server/protocol/v0_8/BrokerDecoder.java > Line 78 processAMQPFrames() - Non-final methods that perform security checks > may be overridden in ways that bypass security checks. > Executes privileged action. > broker-core/src/main/java/org/apache/qpid/server/security/CompoundAccessControl.java > Line 68 newToken() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-10-protocol/src/main/java/org/apache/qpid/server/protocol/v0_10/ServerAssembler.java > Line 72 received() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/amqp-0-10-protocol/src/main/java/org/apache/qpid/server/protocol/v0_10/AMQPConnection_0_10Impl.java > Line 165 readerIdle() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 182 closed() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/management-amqp/src/main/java/org/apache/qpid/server/management/amqp/ProxyMessageSource.java > Line 152 addConsumer() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > broker-plugins/management-amqp/src/main/java/org/apache/qpid/server/management/amqp/ManagementAddressSpace.java > Line 172 getProxyNode() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > broker-plugins/logging-logback/src/main/java/org/apache/qpid/server/logging/logback/PrincipalLogEventFilter.java > Line 43 decide() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/src/main/java/org/apache/qpid/server/protocol/v0_8/AMQChannel.java > Line 303 receivedComplete() -
[jira] [Updated] (QPID-8553) [Broker-J] Improve NPE checks
[ https://issues.apache.org/jira/browse/QPID-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8553: - Fix Version/s: (was: qpid-java-broker-8.0.6) > [Broker-J] Improve NPE checks > - > > Key: QPID-8553 > URL: https://issues.apache.org/jira/browse/QPID-8553 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Daniil Kirilyuk >Priority: Minor > > HP Fortify complains that classes defining security may be overridden by > sub-classes and thereby by-passing the security features: > broker-plugins/access-control/src/main/org/apache/qpid/server/security/access/config/RuleBasedAccessControl.java > Line 58 newToken() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 75 authorise() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-core/src/main/java/org/apache/qpid/server/model/BrokerImpl.java > Line 1022 getConnectionMetaData() - Non-final methods that perform security > checks may be overridden in ways that bypass security checks. > Line 1046 getGroups() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/management-http/src/main/org/apache/qpid/server/management/plugin/servlet/rest/SaslServlet.java > Line 79 doGet() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/org/apache/qpid/server/protocol/v0_8/AMQPConnection_0_8Impl.java > Line 699 readerIdle() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/logging-logback/src/main/org/apache/qpid/server/logging/logback/ConnectionAndUserPredicate.java > Line 43 evaluate() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-1-0-protocol/src/main/org/apache/qpid/server/protocol/v1_0/AMQPConnection_1_0Impl.java > Line 444 receive() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 1269 readerIdle() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > Line 1340 receivedComplete() - Non-final methods that perform security checks > may be overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/src/main/org/apache/qpid/server/protocol/v0_8/BrokerDecoder.java > Line 78 processAMQPFrames() - Non-final methods that perform security checks > may be overridden in ways that bypass security checks. > Executes privileged action. > broker-core/src/main/java/org/apache/qpid/server/security/CompoundAccessControl.java > Line 68 newToken() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-10-protocol/src/main/java/org/apache/qpid/server/protocol/v0_10/ServerAssembler.java > Line 72 received() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/amqp-0-10-protocol/src/main/java/org/apache/qpid/server/protocol/v0_10/AMQPConnection_0_10Impl.java > Line 165 readerIdle() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 182 closed() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/management-amqp/src/main/java/org/apache/qpid/server/management/amqp/ProxyMessageSource.java > Line 152 addConsumer() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > broker-plugins/management-amqp/src/main/java/org/apache/qpid/server/management/amqp/ManagementAddressSpace.java > Line 172 getProxyNode() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > broker-plugins/logging-logback/src/main/java/org/apache/qpid/server/logging/logback/PrincipalLogEventFilter.java > Line 43 decide() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/src/main/java/org/apache/qpid/server/protocol/v0_8/AMQChannel.java > Line 303 receivedComplete() - Non-final methods that perform security checks
[jira] [Updated] (QPID-8553) [Broker-J] Improve NPE checks
[ https://issues.apache.org/jira/browse/QPID-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8553: - Fix Version/s: qpid-java-broker-8.0.6 > [Broker-J] Improve NPE checks > - > > Key: QPID-8553 > URL: https://issues.apache.org/jira/browse/QPID-8553 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Daniil Kirilyuk >Priority: Minor > Fix For: qpid-java-broker-8.0.6 > > > HP Fortify complains that classes defining security may be overridden by > sub-classes and thereby by-passing the security features: > broker-plugins/access-control/src/main/org/apache/qpid/server/security/access/config/RuleBasedAccessControl.java > Line 58 newToken() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 75 authorise() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-core/src/main/java/org/apache/qpid/server/model/BrokerImpl.java > Line 1022 getConnectionMetaData() - Non-final methods that perform security > checks may be overridden in ways that bypass security checks. > Line 1046 getGroups() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/management-http/src/main/org/apache/qpid/server/management/plugin/servlet/rest/SaslServlet.java > Line 79 doGet() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/org/apache/qpid/server/protocol/v0_8/AMQPConnection_0_8Impl.java > Line 699 readerIdle() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/logging-logback/src/main/org/apache/qpid/server/logging/logback/ConnectionAndUserPredicate.java > Line 43 evaluate() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-1-0-protocol/src/main/org/apache/qpid/server/protocol/v1_0/AMQPConnection_1_0Impl.java > Line 444 receive() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 1269 readerIdle() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > Line 1340 receivedComplete() - Non-final methods that perform security checks > may be overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/src/main/org/apache/qpid/server/protocol/v0_8/BrokerDecoder.java > Line 78 processAMQPFrames() - Non-final methods that perform security checks > may be overridden in ways that bypass security checks. > Executes privileged action. > broker-core/src/main/java/org/apache/qpid/server/security/CompoundAccessControl.java > Line 68 newToken() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-10-protocol/src/main/java/org/apache/qpid/server/protocol/v0_10/ServerAssembler.java > Line 72 received() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/amqp-0-10-protocol/src/main/java/org/apache/qpid/server/protocol/v0_10/AMQPConnection_0_10Impl.java > Line 165 readerIdle() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 182 closed() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/management-amqp/src/main/java/org/apache/qpid/server/management/amqp/ProxyMessageSource.java > Line 152 addConsumer() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > broker-plugins/management-amqp/src/main/java/org/apache/qpid/server/management/amqp/ManagementAddressSpace.java > Line 172 getProxyNode() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > broker-plugins/logging-logback/src/main/java/org/apache/qpid/server/logging/logback/PrincipalLogEventFilter.java > Line 43 decide() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/src/main/java/org/apache/qpid/server/protocol/v0_8/AMQChannel.java > Line 303 receivedComplete() -
[jira] [Updated] (QPID-8553) [Broker-J] Improve NPE checks
[ https://issues.apache.org/jira/browse/QPID-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8553: - Summary: [Broker-J] Improve NPE checks (was: [Broker-J] HP Fortify: Weak SecurityManager Check: Overridable Method) > [Broker-J] Improve NPE checks > - > > Key: QPID-8553 > URL: https://issues.apache.org/jira/browse/QPID-8553 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Daniil Kirilyuk >Priority: Minor > > HP Fortify complains that classes defining security may be overridden by > sub-classes and thereby by-passing the security features: > broker-plugins/access-control/src/main/org/apache/qpid/server/security/access/config/RuleBasedAccessControl.java > Line 58 newToken() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 75 authorise() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-core/src/main/java/org/apache/qpid/server/model/BrokerImpl.java > Line 1022 getConnectionMetaData() - Non-final methods that perform security > checks may be overridden in ways that bypass security checks. > Line 1046 getGroups() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/management-http/src/main/org/apache/qpid/server/management/plugin/servlet/rest/SaslServlet.java > Line 79 doGet() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/org/apache/qpid/server/protocol/v0_8/AMQPConnection_0_8Impl.java > Line 699 readerIdle() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/logging-logback/src/main/org/apache/qpid/server/logging/logback/ConnectionAndUserPredicate.java > Line 43 evaluate() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-1-0-protocol/src/main/org/apache/qpid/server/protocol/v1_0/AMQPConnection_1_0Impl.java > Line 444 receive() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 1269 readerIdle() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > Line 1340 receivedComplete() - Non-final methods that perform security checks > may be overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/src/main/org/apache/qpid/server/protocol/v0_8/BrokerDecoder.java > Line 78 processAMQPFrames() - Non-final methods that perform security checks > may be overridden in ways that bypass security checks. > Executes privileged action. > broker-core/src/main/java/org/apache/qpid/server/security/CompoundAccessControl.java > Line 68 newToken() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-10-protocol/src/main/java/org/apache/qpid/server/protocol/v0_10/ServerAssembler.java > Line 72 received() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/amqp-0-10-protocol/src/main/java/org/apache/qpid/server/protocol/v0_10/AMQPConnection_0_10Impl.java > Line 165 readerIdle() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Line 182 closed() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > Executes privileged action. > broker-plugins/management-amqp/src/main/java/org/apache/qpid/server/management/amqp/ProxyMessageSource.java > Line 152 addConsumer() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > broker-plugins/management-amqp/src/main/java/org/apache/qpid/server/management/amqp/ManagementAddressSpace.java > Line 172 getProxyNode() - Non-final methods that perform security checks may > be overridden in ways that bypass security checks. > broker-plugins/logging-logback/src/main/java/org/apache/qpid/server/logging/logback/PrincipalLogEventFilter.java > Line 43 decide() - Non-final methods that perform security checks may be > overridden in ways that bypass security checks. > broker-plugins/amqp-0-8-protocol/src/main/java/org/apache/qpid/server/protocol/v0_8/AMQChannel.java > Lin
[jira] [Updated] (QPID-8556) [Broker-J] Expose virtual host threshold for triggering flow to disk on direct memory utilization
[
https://issues.apache.org/jira/browse/QPID-8556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8556:
-
Description: The virtual host {{#TargetSize}} is used to trigger flow to
disk, when direct memory utilization reaches {{#TargetSize}}. In order to
improve Broker-J direct memory usage monitoring, the {{#TargetSize}} needs to
be exposed as point in time statistics. (was: The virtual host
{{#TargetSize}} is used to trigger flow to disk, when direct memory utilization
reaches {{#TargetSize}}. In order to improve Broker-J direct memory usage
monitoring, the {{#TargetSize}} needs to be exposed as derived attribute.)
Summary: [Broker-J] Expose virtual host threshold for triggering flow
to disk on direct memory utilization (was: [Broker-J] Expose virtual host
direct memory limits as derived attributes)
> [Broker-J] Expose virtual host threshold for triggering flow to disk on
> direct memory utilization
> -
>
> Key: QPID-8556
> URL: https://issues.apache.org/jira/browse/QPID-8556
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.6
>
>
> The virtual host {{#TargetSize}} is used to trigger flow to disk, when
> direct memory utilization reaches {{#TargetSize}}. In order to improve
> Broker-J direct memory usage monitoring, the {{#TargetSize}} needs to be
> exposed as point in time statistics.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8556) [Broker-J] Expose virtual host direct memory limits as derived attributes
Alex Rudyy created QPID-8556:
Summary: [Broker-J] Expose virtual host direct memory limits as
derived attributes
Key: QPID-8556
URL: https://issues.apache.org/jira/browse/QPID-8556
Project: Qpid
Issue Type: Bug
Components: Broker-J
Reporter: Alex Rudyy
Fix For: qpid-java-broker-8.0.6
The virtual host {{#TargetSize}} is used to trigger flow to disk, when direct
memory utilization reaches {{#TargetSize}}. In order to improve Broker-J direct
memory usage monitoring, the {{#TargetSize}} needs to be exposed as derived
attribute.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8555) [Broker-J] Http management does not allow to set OPTIONS method in attribute for CORS allowed methods
[ https://issues.apache.org/jira/browse/QPID-8555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8555. -- Resolution: Fixed > [Broker-J] Http management does not allow to set OPTIONS method in attribute > for CORS allowed methods > -- > > Key: QPID-8555 > URL: https://issues.apache.org/jira/browse/QPID-8555 > Project: Qpid > Issue Type: Bug > Components: Broker-J > Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > > Http management offers to set method OPTION instead of OPTIONS in attribute > for CORS allowed methods -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8552) [Broker-J] Http management interface should ignore OPTIONS command
[ https://issues.apache.org/jira/browse/QPID-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8552. -- Resolution: Fixed > [Broker-J] Http management interface should ignore OPTIONS command > -- > > Key: QPID-8552 > URL: https://issues.apache.org/jira/browse/QPID-8552 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Tom Jordahl >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > Attachments: forbid-options.patch > > > Many security scanning tools flag HTTP ports that respond to the OPTIONS > command. > Broker-J already blocks the TRACE command, it should also block the OPTIONS > command. > There are various ways of configuring Jetty to do this, but I have attached a > patch that mirrors the filter that blocks TRACE. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8555) [Broker-J] Http management does not allow to set OPTIONS method in attribute for CORS allowed methods
Alex Rudyy created QPID-8555: Summary: [Broker-J] Http management does not allow to set OPTIONS method in attribute for CORS allowed methods Key: QPID-8555 URL: https://issues.apache.org/jira/browse/QPID-8555 Project: Qpid Issue Type: Bug Components: Broker-J Reporter: Alex Rudyy Fix For: qpid-java-broker-8.0.6 Http management offers to set method OPTION instead of OPTIONS in attribute for CORS allowed methods -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8552) [Broker-J] Http management interface should ignore OPTIONS command
[ https://issues.apache.org/jira/browse/QPID-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-8552: Assignee: Alex Rudyy > [Broker-J] Http management interface should ignore OPTIONS command > -- > > Key: QPID-8552 > URL: https://issues.apache.org/jira/browse/QPID-8552 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Tom Jordahl >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > Attachments: forbid-options.patch > > > Many security scanning tools flag HTTP ports that respond to the OPTIONS > command. > Broker-J already blocks the TRACE command, it should also block the OPTIONS > command. > There are various ways of configuring Jetty to do this, but I have attached a > patch that mirrors the filter that blocks TRACE. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8552) [Broker-J] Http management interface should ignore OPTIONS command
[ https://issues.apache.org/jira/browse/QPID-8552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8552: - Fix Version/s: qpid-java-broker-8.0.6 > [Broker-J] Http management interface should ignore OPTIONS command > -- > > Key: QPID-8552 > URL: https://issues.apache.org/jira/browse/QPID-8552 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.5 >Reporter: Tom Jordahl >Priority: Major > Fix For: qpid-java-broker-8.0.6 > > Attachments: forbid-options.patch > > > Many security scanning tools flag HTTP ports that respond to the OPTIONS > command. > Broker-J already blocks the TRACE command, it should also block the OPTIONS > command. > There are various ways of configuring Jetty to do this, but I have attached a > patch that mirrors the filter that blocks TRACE. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8551) [JMS AMQP 0-x] The reject per formatives are sent twice on rollback of asynchronous consumer transactions
Alex Rudyy created QPID-8551:
Summary: [JMS AMQP 0-x] The reject per formatives are sent twice
on rollback of asynchronous consumer transactions
Key: QPID-8551
URL: https://issues.apache.org/jira/browse/QPID-8551
Project: Qpid
Issue Type: Bug
Components: JMS AMQP 0-x
Affects Versions: qpid-java-client-0-x-6.4.0, qpid-java-client-0-x-6.3.4,
qpid-java-client-0-x-6.3.3, qpid-java-client-0-x-6.3.2,
qpid-java-client-0-x-6.3.1, qpid-java-client-0-x-6.3.0
Reporter: Alex Rudyy
When consumer transaction is rolled back, the dispatch queue is cleaned by
invoking {{syncDispatchQueue(false)}}. That results in invocation of
{{dispatchMessage(UnprocessedMessage message)}}. The latter sends reject
commands for all tags below rollback threshold:
{code}
if (!(message instanceof CloseConsumerMessage) && tagLE(deliveryTag,
_rollbackMark.get()))
{
if (_logger.isDebugEnabled())
{
_logger.debug("Rejecting message because delivery tag "
+ deliveryTag
+ " <= rollback mark " + _rollbackMark.get());
}
rejectMessage(message, true);
}
{code}
Though, the code above does not remove rejected message from
{{_deliveredMessageTags}}.
As result, the rejects are sent again on invocation of {{releaseForRollback()}}
which is called from {{AMQSession#rollback()}}.
The issue affects only consumer transactions when {{MessageListener}} is used
to receive the message.
The work around for the defect would be to use synchronous consumer for message
receiving.
It looks like the issue can be fixed by removal of the rejected message from
{{_deliveredMessageTags}} in {{dispatchMessage(UnprocessedMessage message)}}.
{code}:
diff --git a/client/src/main/java/org/apache/qpid/client/AMQSession.java
b/client/src/main/java/org/apache/qpid/client/AMQSession.java
index 125cba1dd..7f7a5a283 100644
--- a/client/src/main/java/org/apache/qpid/client/AMQSession.java
+++ b/client/src/main/java/org/apache/qpid/client/AMQSession.java
@@ -3621,6 +3621,7 @@ public abstract class AMQSession
[jira] [Comment Edited] (QPID-8534) [Broker-J] Improper interruption of connection processing loop
[
https://issues.apache.org/jira/browse/QPID-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374329#comment-17374329
]
Alex Rudyy edited comment on QPID-8534 at 7/4/21, 5:00 PM:
---
I do not think that this JIRA is correct.
The reason why connection {{#doWork}} is mainly invoked once is to keep
"fairness", especially when all IO threads are used. Though, that might result
in more frequent connection re-scheduling even for situations when there are
data to read or write, the current implementation guarantees some level of
fairness - each connection with "work" would have its chance to get invoked.
Otherwise, the connections with more work (big messages or more frequent IO
operations) would be dominating IO threads and blocking other connections with
smaller messages or less frequent IO operations.
Thus, the current implementation is by design.
I agree that implemented code is complex. I do not mind re-factoring to make it
simpler. However, it needs to be done with keeping existing behaviour including
fairness...
was (Author: alex.rufous):
I do not think that this JIRA is correct.
The reason why connections {{#doWork}} is mainly invoked once is to keep
"fairness", especially when all IO threads are used. Though, that might result
in more frequent connection re-scheduling even for situations when there are
data to read or write, the current implementation guarantees some level of
fairness - each connection with "work" would have its chance to get invoked.
Otherwise, the connections with more work (big messages or more frequent IO
operations) would be dominating IO threads and blocking other connections with
smaller messages or less frequent IO operations.
Thus, the current implementation is by design.
I agree that implemented code is complex. I do not mind re-factoring to make it
simpler. However, it needs to be done with keeping existing behaviour including
fairness...
> [Broker-J] Improper interruption of connection processing loop
> --
>
> Key: QPID-8534
> URL: https://issues.apache.org/jira/browse/QPID-8534
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Marek Laca
>Priority: Minor
> Labels: Broker, Connection, Java
>
> The network connection scheduler (NetworkConnectionScheduler class) contains
> a thread pool. IO-threads are polling jobs from the scheduler work queue and
> executing them. The connection job works in the loop. The loop is interrupted
> when there is not any data to process or all IO-threads are occupied.
> If the loop is interrupted then the IO-thread pushes the connection job back
> into the queue and picks the next job from the queue. It should ensure that
> any job is not abandoned and it is not waiting in the queue for ever.
> But when the number of jobs equals to the thread pool size then IO-thread
> stops processing the connection job, pushes it back into the queue and polls
> the same job again, again and again.
> The connection job could check whether is there any job in the scheduler
> queue. If the queue was not empty then the connection working loop would be
> interrupted and the thread could pick up another job. It would simplified the
> broker code significantly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8534) [Broker-J] Improper interruption of connection processing loop
[
https://issues.apache.org/jira/browse/QPID-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374329#comment-17374329
]
Alex Rudyy edited comment on QPID-8534 at 7/4/21, 5:00 PM:
---
I do not think that this JIRA is correct.
The reason why connections {{#doWork}} is mainly invoked once is to keep
"fairness", especially when all IO threads are used. Though, that might result
in more frequent connection re-scheduling even for situations when there are
data to read or write, the current implementation guarantees some level of
fairness - each connection with "work" would have its chance to get invoked.
Otherwise, the connections with more work (big messages or more frequent IO
operations) would be dominating IO threads and blocking other connections with
smaller messages or less frequent IO operations.
Thus, the current implementation is by design.
I agree that implemented code is complex. I do not mind re-factoring to make it
simpler. However, it needs to be done with keeping existing behaviour including
fairness...
was (Author: alex.rufous):
I do not think that this JIRA is correct.
The reason why connections `#doWork` is mainly invoked once is to keep
"fairness", especially when all IO threads are used. Though, that might result
in more frequent connection re-scheduling even for situations when there are
data to read or write, the current implementation guarantees some level of
fairness - each connection with "work" would have its chance to get invoked.
Otherwise, the connections with more work (big messages or more frequent IO
operations) would be dominating IO threads and blocking other connections with
smaller messages or less frequent IO operations.
Thus, the current implementation is by design.
I agree that implemented code is complex. I do not mind re-factoring to make it
simpler. However, it needs to be done with keeping existing behaviour including
fairness...
> [Broker-J] Improper interruption of connection processing loop
> --
>
> Key: QPID-8534
> URL: https://issues.apache.org/jira/browse/QPID-8534
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Marek Laca
>Priority: Minor
> Labels: Broker, Connection, Java
>
> The network connection scheduler (NetworkConnectionScheduler class) contains
> a thread pool. IO-threads are polling jobs from the scheduler work queue and
> executing them. The connection job works in the loop. The loop is interrupted
> when there is not any data to process or all IO-threads are occupied.
> If the loop is interrupted then the IO-thread pushes the connection job back
> into the queue and picks the next job from the queue. It should ensure that
> any job is not abandoned and it is not waiting in the queue for ever.
> But when the number of jobs equals to the thread pool size then IO-thread
> stops processing the connection job, pushes it back into the queue and polls
> the same job again, again and again.
> The connection job could check whether is there any job in the scheduler
> queue. If the queue was not empty then the connection working loop would be
> interrupted and the thread could pick up another job. It would simplified the
> broker code significantly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8534) [Broker-J] Improper interruption of connection processing loop
[ https://issues.apache.org/jira/browse/QPID-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374329#comment-17374329 ] Alex Rudyy commented on QPID-8534: -- I do not think that this JIRA is correct. The reason why connections `#doWork` is mainly invoked once is to keep "fairness", especially when all IO threads are used. Though, that might result in more frequent connection re-scheduling even for situations when there are data to read or write, the current implementation guarantees some level of fairness - each connection with "work" would have its chance to get invoked. Otherwise, the connections with more work (big messages or more frequent IO operations) would be dominating IO threads and blocking other connections with smaller messages or less frequent IO operations. Thus, the current implementation is by design. I agree that implemented code is complex. I do not mind re-factoring to make it simpler. However, it needs to be done with keeping existing behaviour including fairness... > [Broker-J] Improper interruption of connection processing loop > -- > > Key: QPID-8534 > URL: https://issues.apache.org/jira/browse/QPID-8534 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Marek Laca >Priority: Minor > Labels: Broker, Connection, Java > > The network connection scheduler (NetworkConnectionScheduler class) contains > a thread pool. IO-threads are polling jobs from the scheduler work queue and > executing them. The connection job works in the loop. The loop is interrupted > when there is not any data to process or all IO-threads are occupied. > If the loop is interrupted then the IO-thread pushes the connection job back > into the queue and picks the next job from the queue. It should ensure that > any job is not abandoned and it is not waiting in the queue for ever. > But when the number of jobs equals to the thread pool size then IO-thread > stops processing the connection job, pushes it back into the queue and polls > the same job again, again and again. > The connection job could check whether is there any job in the scheduler > queue. If the queue was not empty then the connection working loop would be > interrupted and the thread could pick up another job. It would simplified the > broker code significantly. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[ANNOUNCE] Apache Qpid Broker-J 8.0.5 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid Broker-J 8.0.5. This is the latest release of pure java implementation of messaging broker supporting the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org) and legacy AMQP protocols 0-10, 0-91, 0-9 and 0-8. Please visit Qpid project site for more details: http://qpid.apache.org/components/broker-j/index.html The release is available now from our website: http://qpid.apache.org/download.html The release brings bug fixes and improvements. The release notes can be found at: http://qpid.apache.org/releases/qpid-broker-j-8.0.5/release-notes.html Thanks to all involved, Qpid Team - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8510) [Broker-J] [AMQP 1.0] Connection transaction management is not thread-safe
[
https://issues.apache.org/jira/browse/QPID-8510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8510:
-
Summary: [Broker-J] [AMQP 1.0] Connection transaction management is not
thread-safe (was: [Broker-J] Connection transaction management is not
thread-safe)
> [Broker-J] [AMQP 1.0] Connection transaction management is not thread-safe
> --
>
> Key: QPID-8510
> URL: https://issues.apache.org/jira/browse/QPID-8510
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0, qpid-java-broker-7.0.1,
> qpid-java-broker-7.1.0, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5,
> qpid-java-broker-7.0.6, qpid-java-broker-7.0.7, qpid-java-broker-8.0.0,
> qpid-java-broker-7.1.1, qpid-java-broker-7.1.2, qpid-java-broker-7.0.8,
> qpid-java-broker-7.1.3, qpid-java-broker-7.1.4, qpid-java-broker-7.0.9,
> qpid-java-broker-7.1.5, qpid-java-broker-7.1.6, qpid-java-broker-7.1.7,
> qpid-java-broker-7.1.8, qpid-java-broker-8.0.1, qpid-java-broker-7.1.9,
> qpid-java-broker-8.0.2, qpid-java-broker-7.1.10, qpid-java-broker-8.0.3,
> qpid-java-broker-7.1.11, qpid-java-broker-8.0.4, qpid-java-broker-7.1.12
>Reporter: Marek Laca
>Priority: Minor
> Labels: Broker, Java
> Fix For: qpid-java-broker-8.0.5
>
>
> Based on Java documentation a change of volatile variable is always visible
> to other threads. Hence, assignment a new array to the volatile variable
> guarantees the visibility of the new array to another threads, but there is
> not any guarantee of the visibility of a new element of the array. Because
> the insertion of a new element into the volatile array is a change of the
> internal state of the array.
> For example there is the method AMQPConnection_1_0Impl::removeTransaction:
> {code:java}
> private volatile ServerTransaction[] _openTransactions = new
> ServerTransaction[16];
> @Override
> public void removeTransaction(final int txnId)
> {
> try
> {
> _openTransactions[txnId] = null; // There is not any guarantee
> of the visibility, when the change is propagated to another threads.
> }
> catch (ArrayIndexOutOfBoundsException e)
> {
> throw new UnknownTransactionException(txnId);
> }
> }
> {code}
> The same issue is in other methods of AMQPConnection_1_0Impl class.
> A concurrent collection can be used instead of the volatile array.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8510) [Broker-J] Connection transaction management is not thread-safe
[
https://issues.apache.org/jira/browse/QPID-8510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8510:
-
Summary: [Broker-J] Connection transaction management is not thread-safe
(was: [Broker-J] Incorect use of volatile modifier for array)
> [Broker-J] Connection transaction management is not thread-safe
> ---
>
> Key: QPID-8510
> URL: https://issues.apache.org/jira/browse/QPID-8510
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0, qpid-java-broker-7.0.1,
> qpid-java-broker-7.1.0, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5,
> qpid-java-broker-7.0.6, qpid-java-broker-7.0.7, qpid-java-broker-8.0.0,
> qpid-java-broker-7.1.1, qpid-java-broker-7.1.2, qpid-java-broker-7.0.8,
> qpid-java-broker-7.1.3, qpid-java-broker-7.1.4, qpid-java-broker-7.0.9,
> qpid-java-broker-7.1.5, qpid-java-broker-7.1.6, qpid-java-broker-7.1.7,
> qpid-java-broker-7.1.8, qpid-java-broker-8.0.1, qpid-java-broker-7.1.9,
> qpid-java-broker-8.0.2, qpid-java-broker-7.1.10, qpid-java-broker-8.0.3,
> qpid-java-broker-7.1.11, qpid-java-broker-8.0.4, qpid-java-broker-7.1.12
>Reporter: Marek Laca
>Priority: Minor
> Labels: Broker, Java
> Fix For: qpid-java-broker-8.0.5
>
>
> Based on Java documentation a change of volatile variable is always visible
> to other threads. Hence, assignment a new array to the volatile variable
> guarantees the visibility of the new array to another threads, but there is
> not any guarantee of the visibility of a new element of the array. Because
> the insertion of a new element into the volatile array is a change of the
> internal state of the array.
> For example there is the method AMQPConnection_1_0Impl::removeTransaction:
> {code:java}
> private volatile ServerTransaction[] _openTransactions = new
> ServerTransaction[16];
> @Override
> public void removeTransaction(final int txnId)
> {
> try
> {
> _openTransactions[txnId] = null; // There is not any guarantee
> of the visibility, when the change is propagated to another threads.
> }
> catch (ArrayIndexOutOfBoundsException e)
> {
> throw new UnknownTransactionException(txnId);
> }
> }
> {code}
> The same issue is in other methods of AMQPConnection_1_0Impl class.
> A concurrent collection can be used instead of the volatile array.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8529) [Broker-J] NPE when trying to access cached user credentials
[ https://issues.apache.org/jira/browse/QPID-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8529: - Summary: [Broker-J] NPE when trying to access cached user credentials (was: [Broker-J] NPE when trying to access digestCrecentials in the cached mode) > [Broker-J] NPE when trying to access cached user credentials > > > Key: QPID-8529 > URL: https://issues.apache.org/jira/browse/QPID-8529 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.4 >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.5 > > > There is a NPE thrown when trying to digest the credentials from the cache. > Below is the stack trace > 2021-05-21T13:58:19,703Z WARN [qtp1216638014-207] (o.e.j.s.HttpChannel) - > /2021-05-21T13:58:19,703Z WARN [qtp1216638014-207] (o.e.j.s.HttpChannel) - > /java.lang.NullPointerException: null at > org.apache.qpid.server.security.auth.manager.AuthenticationResultCacher.digestCredentials(AuthenticationResultCacher.java:118) > at > org.apache.qpid.server.security.auth.manager.AuthenticationResultCacher.getOrLoad(AuthenticationResultCacher.java:82) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8540) [Broker-J] Release Qpid Broker-J 8.0.5
[ https://issues.apache.org/jira/browse/QPID-8540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8540. -- Resolution: Fixed > [Broker-J] Release Qpid Broker-J 8.0.5 > -- > > Key: QPID-8540 > URL: https://issues.apache.org/jira/browse/QPID-8540 > Project: Qpid > Issue Type: Task > Components: Broker-J > Reporter: Alex Rudyy > Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.5 > > > Release Qpid Broker-J 8.0.5 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8529) [Broker-J] NPE when trying to access digestCrecentials in the cached mode
[ https://issues.apache.org/jira/browse/QPID-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8529: - Issue Type: Bug (was: Improvement) > [Broker-J] NPE when trying to access digestCrecentials in the cached mode > - > > Key: QPID-8529 > URL: https://issues.apache.org/jira/browse/QPID-8529 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.4 >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.5 > > > There is a NPE thrown when trying to digest the credentials from the cache. > Below is the stack trace > 2021-05-21T13:58:19,703Z WARN [qtp1216638014-207] (o.e.j.s.HttpChannel) - > /2021-05-21T13:58:19,703Z WARN [qtp1216638014-207] (o.e.j.s.HttpChannel) - > /java.lang.NullPointerException: null at > org.apache.qpid.server.security.auth.manager.AuthenticationResultCacher.digestCredentials(AuthenticationResultCacher.java:118) > at > org.apache.qpid.server.security.auth.manager.AuthenticationResultCacher.getOrLoad(AuthenticationResultCacher.java:82) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8511) [Broker-J] Upgrade dojotoolkit to version 1.16.3
[
https://issues.apache.org/jira/browse/QPID-8511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8511:
-
Issue Type: Improvement (was: Task)
> [Broker-J] Upgrade dojotoolkit to version 1.16.3
>
>
> Key: QPID-8511
> URL: https://issues.apache.org/jira/browse/QPID-8511
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.5
>
>
> A security vulnerability
> [CVE-2020-5258|https://nvd.nist.gov/vuln/detail/CVE-2020-5258] is reported
> against dojo-toolkit version 1.16.0.
> {quote}
> A deepCopy method is vulnerable to Prototype Pollution. Prototype Pollution
> refers to the ability to inject properties into existing JavaScript language
> construct prototypes, such as objects. An attacker manipulates these
> attributes to overwrite, or pollute, a JavaScript application object
> prototype of the base object by injecting other values.
> {quote}
> Even when vulnerability attack is successful and UI is affected by the
> injected code, it is not expected that it would have any bearing on Qpid REST
> API and messaging functionality.
> In order to prevent various scanning tools from flagging the issue, we need
> to upgrade dojotollkit to version 1.16.3
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8541) [Broker-J] Enhance Broker Rest API to include certificate alias
[ https://issues.apache.org/jira/browse/QPID-8541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8541. -- Resolution: Fixed > [Broker-J] Enhance Broker Rest API to include certificate alias > --- > > Key: QPID-8541 > URL: https://issues.apache.org/jira/browse/QPID-8541 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Marek Laca >Priority: Minor > Labels: Alias, Broker, Certificate, Java > Fix For: qpid-java-broker-8.0.6 > > > Java broker can publish the list of details about certificates that are hold > in the broker trust store via rest API. > Broker has 4 types of trust store: > * FileTrustStore > * NonJavaTrustStore > * ManagedPeerCertificateTrustStore > * SiteSpecificTrustStore > FileTrustStore is based on the Java KeyStore, but the certificate alias is > not published in the certificate details. But the certificate alias is very > useful for managing the underlying Java KeyStore. The task is to enhance the > FileTrustStore and include the alias from underlying KeyStore in certificate > details. The alias should be accessible via Rest API and the broker GUI. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8541) [Broker-J] Enhance Broker Rest API to include certificate alias
[ https://issues.apache.org/jira/browse/QPID-8541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8541: - Fix Version/s: qpid-java-broker-8.0.6 > [Broker-J] Enhance Broker Rest API to include certificate alias > --- > > Key: QPID-8541 > URL: https://issues.apache.org/jira/browse/QPID-8541 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Marek Laca >Priority: Minor > Labels: Alias, Broker, Certificate, Java > Fix For: qpid-java-broker-8.0.6 > > > Java broker can publish the list of details about certificates that are hold > in the broker trust store via rest API. > Broker has 4 types of trust store: > * FileTrustStore > * NonJavaTrustStore > * ManagedPeerCertificateTrustStore > * SiteSpecificTrustStore > FileTrustStore is based on the Java KeyStore, but the certificate alias is > not published in the certificate details. But the certificate alias is very > useful for managing the underlying Java KeyStore. The task is to enhance the > FileTrustStore and include the alias from underlying KeyStore in certificate > details. The alias should be accessible via Rest API and the broker GUI. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8541) [Broker-J] Enhance Broker Rest API to include certificate alias
[ https://issues.apache.org/jira/browse/QPID-8541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364165#comment-17364165 ] Alex Rudyy commented on QPID-8541: -- Hi [~lacam], Would you like to merge the corresponding changes into 8.0.x branch to include in one of upcoming 8.0.x releases? It is a bit late for 8.0.5, but I can add the changes into 8.0.6 release... > [Broker-J] Enhance Broker Rest API to include certificate alias > --- > > Key: QPID-8541 > URL: https://issues.apache.org/jira/browse/QPID-8541 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Marek Laca >Priority: Minor > Labels: Alias, Broker, Certificate, Java > > Java broker can publish the list of details about certificates that are hold > in the broker trust store via rest API. > Broker has 4 types of trust store: > * FileTrustStore > * NonJavaTrustStore > * ManagedPeerCertificateTrustStore > * SiteSpecificTrustStore > FileTrustStore is based on the Java KeyStore, but the certificate alias is > not published in the certificate details. But the certificate alias is very > useful for managing the underlying Java KeyStore. The task is to enhance the > FileTrustStore and include the alias from underlying KeyStore in certificate > details. The alias should be accessible via Rest API and the broker GUI. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8540) [Broker-J] Release Qpid Broker-J 8.0.5
[ https://issues.apache.org/jira/browse/QPID-8540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-8540: Assignee: Alex Rudyy > [Broker-J] Release Qpid Broker-J 8.0.5 > -- > > Key: QPID-8540 > URL: https://issues.apache.org/jira/browse/QPID-8540 > Project: Qpid > Issue Type: Task > Components: Broker-J > Reporter: Alex Rudyy > Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.5 > > > Release Qpid Broker-J 8.0.5 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8540) [Broker-J] Release Qpid Broker-J 8.0.5
Alex Rudyy created QPID-8540: Summary: [Broker-J] Release Qpid Broker-J 8.0.5 Key: QPID-8540 URL: https://issues.apache.org/jira/browse/QPID-8540 Project: Qpid Issue Type: Task Components: Broker-J Reporter: Alex Rudyy Fix For: qpid-java-broker-8.0.5 Release Qpid Broker-J 8.0.5 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8539) [Broker-J] Upgrade Jackson version to 2.12.3
[ https://issues.apache.org/jira/browse/QPID-8539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8539. -- Resolution: Fixed > [Broker-J] Upgrade Jackson version to 2.12.3 > > > Key: QPID-8539 > URL: https://issues.apache.org/jira/browse/QPID-8539 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.5 > > > The jackson core and databind versions are bumped to 2.12.3. So upgrading them -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8539) [Broker-J] Upgrade Jackson version to 2.12.3
[ https://issues.apache.org/jira/browse/QPID-8539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8539: - Affects Version/s: (was: qpid-java-broker-8.0.4) > [Broker-J] Upgrade Jackson version to 2.12.3 > > > Key: QPID-8539 > URL: https://issues.apache.org/jira/browse/QPID-8539 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.5 > > > The jackson core and databind versions are bumped to 2.12.3. So upgrading them -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8539) [Broker-J] Upgrade Jackson version to 2.12.3
[ https://issues.apache.org/jira/browse/QPID-8539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8539: - Summary: [Broker-J] Upgrade Jackson version to 2.12.3 (was: Upgrade Jackson version to 2.12.3) > [Broker-J] Upgrade Jackson version to 2.12.3 > > > Key: QPID-8539 > URL: https://issues.apache.org/jira/browse/QPID-8539 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.4 >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.5 > > > The jackson core and databind versions are bumped to 2.12.3. So upgrading them -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8523) [Broker-J] refusing-attach while rejecting consumer does not set required initial-delivery-count field
[
https://issues.apache.org/jira/browse/QPID-8523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8523:
-
Fix Version/s: qpid-java-broker-8.0.6
> [Broker-J] refusing-attach while rejecting consumer does not set required
> initial-delivery-count field
> --
>
> Key: QPID-8523
> URL: https://issues.apache.org/jira/browse/QPID-8523
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.4
>Reporter: Robbie Gemmell
>Priority: Major
> Fix For: qpid-java-broker-8.0.6
>
>
> Attempting to create a consumer link from e.g. a non-existing address results
> in refusal of the link, which in case of a consumer is done by sending a
> 'response' attach with null source to indicate the terminus wasnt created,
> followed by a detach with the error.
> The broker does send an attach without a source, but it omits the
> initialDeliveryCount value from the attach, which the spec says is required
> when role=SENDER ("This MUST NOT be null if role is sender, and it is ignored
> if the role is receiver."). Protocol libraries validating such required
> values will run afoul of this, leading to decode error that can bring the
> connection down unnecessarily.
> From looking at the wire encoding, it appears only the first 3 fields (name,
> handle, role) of the attach are being set, with the rest unpopulated and thus
> being equivalent to null or any default they may have.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (QPID-8523) [Broker-J] refusing-attach while rejecting consumer does not set required initial-delivery-count field
[
https://issues.apache.org/jira/browse/QPID-8523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy reopened QPID-8523:
--
> [Broker-J] refusing-attach while rejecting consumer does not set required
> initial-delivery-count field
> --
>
> Key: QPID-8523
> URL: https://issues.apache.org/jira/browse/QPID-8523
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.4
>Reporter: Robbie Gemmell
>Priority: Major
>
> Attempting to create a consumer link from e.g. a non-existing address results
> in refusal of the link, which in case of a consumer is done by sending a
> 'response' attach with null source to indicate the terminus wasnt created,
> followed by a detach with the error.
> The broker does send an attach without a source, but it omits the
> initialDeliveryCount value from the attach, which the spec says is required
> when role=SENDER ("This MUST NOT be null if role is sender, and it is ignored
> if the role is receiver."). Protocol libraries validating such required
> values will run afoul of this, leading to decode error that can bring the
> connection down unnecessarily.
> From looking at the wire encoding, it appears only the first 3 fields (name,
> handle, role) of the attach are being set, with the rest unpopulated and thus
> being equivalent to null or any default they may have.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8523) [Broker-J] refusing-attach while rejecting consumer does not set required initial-delivery-count field
[
https://issues.apache.org/jira/browse/QPID-8523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363550#comment-17363550
]
Alex Rudyy commented on QPID-8523:
--
Hi [~robbie],
Thanks for a prompt reply about the change and providing hints how to reproduce
the issue. We will look into a proper fix for the reported behaviour. For now,
I would like to de-scope this JIRA from 8.0.5 release. We will try to implement
the fix in next 8.0.6 release.
> [Broker-J] refusing-attach while rejecting consumer does not set required
> initial-delivery-count field
> --
>
> Key: QPID-8523
> URL: https://issues.apache.org/jira/browse/QPID-8523
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.4
>Reporter: Robbie Gemmell
>Priority: Major
> Fix For: qpid-java-broker-8.0.5
>
>
> Attempting to create a consumer link from e.g. a non-existing address results
> in refusal of the link, which in case of a consumer is done by sending a
> 'response' attach with null source to indicate the terminus wasnt created,
> followed by a detach with the error.
> The broker does send an attach without a source, but it omits the
> initialDeliveryCount value from the attach, which the spec says is required
> when role=SENDER ("This MUST NOT be null if role is sender, and it is ignored
> if the role is receiver."). Protocol libraries validating such required
> values will run afoul of this, leading to decode error that can bring the
> connection down unnecessarily.
> From looking at the wire encoding, it appears only the first 3 fields (name,
> handle, role) of the attach are being set, with the rest unpopulated and thus
> being equivalent to null or any default they may have.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8523) [Broker-J] refusing-attach while rejecting consumer does not set required initial-delivery-count field
[
https://issues.apache.org/jira/browse/QPID-8523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8523:
-
Fix Version/s: (was: qpid-java-broker-8.0.5)
> [Broker-J] refusing-attach while rejecting consumer does not set required
> initial-delivery-count field
> --
>
> Key: QPID-8523
> URL: https://issues.apache.org/jira/browse/QPID-8523
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.4
>Reporter: Robbie Gemmell
>Priority: Major
>
> Attempting to create a consumer link from e.g. a non-existing address results
> in refusal of the link, which in case of a consumer is done by sending a
> 'response' attach with null source to indicate the terminus wasnt created,
> followed by a detach with the error.
> The broker does send an attach without a source, but it omits the
> initialDeliveryCount value from the attach, which the spec says is required
> when role=SENDER ("This MUST NOT be null if role is sender, and it is ignored
> if the role is receiver."). Protocol libraries validating such required
> values will run afoul of this, leading to decode error that can bring the
> connection down unnecessarily.
> From looking at the wire encoding, it appears only the first 3 fields (name,
> handle, role) of the attach are being set, with the rest unpopulated and thus
> being equivalent to null or any default they may have.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8520) [Broker-J] ReadPendingException thrown by Broker-J intermittently
[
https://issues.apache.org/jira/browse/QPID-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8520.
--
Resolution: Fixed
> [Broker-J] ReadPendingException thrown by Broker-J intermittently
> -
>
> Key: QPID-8520
> URL: https://issues.apache.org/jira/browse/QPID-8520
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.2
> Environment: Broker-J 8.0.2
> Spring Boot 3.2.2
> Docker Engine v20.10.5
> Testcontainers 1.15.1
>Reporter: Kyrre
>Priority: Major
> Fix For: qpid-java-broker-8.0.5
>
>
> Our project is using the HTTPS management interface, using a REST client.
> We've wrapped our qpid instance in a Docker container using testcontainers,
> and have a test that sets up and tears down different elements we utilise in
> our system with asserts that things are as we expected, all this over HTTPS
> between the local machine and the container. This works splendidly, except
> for the fact that we see intermittent errors in the test of the type
> {quote}java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58)
> at
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:362)
> at
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
> at org.eclipse.jetty.server.HttpConnection.onOpen(HttpConnection.java:505)
> at org.eclipse.jetty.io.ssl.SslConnection.onOpen(SslConnection.java:357)
> at
> org.apache.qpid.server.management.plugin.portunification.TlsOrPlainConnectionFactory$PlainOrTlsConnection.onOpen(TlsOrPlainConnectionFactory.java:166)
> at
> org.eclipse.jetty.io.SelectorManager.connectionOpened(SelectorManager.java:324)
> at
> org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:368)
> at org.eclipse.jetty.io.ManagedSelector.access$2000(ManagedSelector.java:62)
> at org.eclipse.jetty.io.ManagedSelector$Accept.run(ManagedSelector.java:853)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
> at java.lang.Thread.run(Thread.java:745)
> {quote}
> This occurs directly after these log lines:
> {quote}2021-04-22 13:42:23,709 WARN [qtp1875836959-116]
> (o.e.j.i.FillInterest) - Read pending for null prevented
> AC.ReadCB@108ec429{HttpConnection@108ec429::DecryptedEndPoint@7cbac9d1{l=/172.17.0.3:443,r=/172.17.0.1:36566,OPEN,fill=-,flush=-,to=2/3}}
> 2021-04-22 13:42:23,721 WARN [qtp1875836959-116] (o.e.j.i.SelectorManager) -
> Exception while notifying connection
> PlainOrTlsConnection@2fb30f4a<-org.apache.qpid.server.management.plugin.portunification.MarkableEndPoint@46d4f493
> {quote}
> From the client side log:
> {quote}org.springframework.web.client.ResourceAccessException: I/O error on
> POST request for
> "https://localhost:49201/api/latest/queue/default/localhost/": Remote host
> terminated the handshake; nested exception is
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> {quote}
> I am fully aware that this might be a bit too little to go by, but I have
> tried in to create a reproducible code snippet, but cannot find a way to make
> the error occur in a stable and reproducible way. I am also aware that this
> might be caused by a number of other things, but figured thia would be a good
> start to try to find out what to do about it.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8520) [Broker-J] ReadPendingException thrown by Broker-J intermittently
[
https://issues.apache.org/jira/browse/QPID-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8520:
-
Summary: [Broker-J] ReadPendingException thrown by Broker-J intermittently
(was: ReadPendingException thrown by Broker-J intermittently)
> [Broker-J] ReadPendingException thrown by Broker-J intermittently
> -
>
> Key: QPID-8520
> URL: https://issues.apache.org/jira/browse/QPID-8520
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.2
> Environment: Broker-J 8.0.2
> Spring Boot 3.2.2
> Docker Engine v20.10.5
> Testcontainers 1.15.1
>Reporter: Kyrre
>Priority: Major
> Fix For: qpid-java-broker-8.0.5
>
>
> Our project is using the HTTPS management interface, using a REST client.
> We've wrapped our qpid instance in a Docker container using testcontainers,
> and have a test that sets up and tears down different elements we utilise in
> our system with asserts that things are as we expected, all this over HTTPS
> between the local machine and the container. This works splendidly, except
> for the fact that we see intermittent errors in the test of the type
> {quote}java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58)
> at
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:362)
> at
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
> at org.eclipse.jetty.server.HttpConnection.onOpen(HttpConnection.java:505)
> at org.eclipse.jetty.io.ssl.SslConnection.onOpen(SslConnection.java:357)
> at
> org.apache.qpid.server.management.plugin.portunification.TlsOrPlainConnectionFactory$PlainOrTlsConnection.onOpen(TlsOrPlainConnectionFactory.java:166)
> at
> org.eclipse.jetty.io.SelectorManager.connectionOpened(SelectorManager.java:324)
> at
> org.eclipse.jetty.io.ManagedSelector.createEndPoint(ManagedSelector.java:368)
> at org.eclipse.jetty.io.ManagedSelector.access$2000(ManagedSelector.java:62)
> at org.eclipse.jetty.io.ManagedSelector$Accept.run(ManagedSelector.java:853)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
> at java.lang.Thread.run(Thread.java:745)
> {quote}
> This occurs directly after these log lines:
> {quote}2021-04-22 13:42:23,709 WARN [qtp1875836959-116]
> (o.e.j.i.FillInterest) - Read pending for null prevented
> AC.ReadCB@108ec429{HttpConnection@108ec429::DecryptedEndPoint@7cbac9d1{l=/172.17.0.3:443,r=/172.17.0.1:36566,OPEN,fill=-,flush=-,to=2/3}}
> 2021-04-22 13:42:23,721 WARN [qtp1875836959-116] (o.e.j.i.SelectorManager) -
> Exception while notifying connection
> PlainOrTlsConnection@2fb30f4a<-org.apache.qpid.server.management.plugin.portunification.MarkableEndPoint@46d4f493
> {quote}
> From the client side log:
> {quote}org.springframework.web.client.ResourceAccessException: I/O error on
> POST request for
> "https://localhost:49201/api/latest/queue/default/localhost/": Remote host
> terminated the handshake; nested exception is
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> {quote}
> I am fully aware that this might be a bit too little to go by, but I have
> tried in to create a reproducible code snippet, but cannot find a way to make
> the error occur in a stable and reproducible way. I am also aware that this
> might be caused by a number of other things, but figured thia would be a good
> start to try to find out what to do about it.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8483) [Broker-J] Change session operational log subject to have a session name in it
[
https://issues.apache.org/jira/browse/QPID-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8483.
--
Resolution: Fixed
> [Broker-J] Change session operational log subject to have a session name in it
> --
>
> Key: QPID-8483
> URL: https://issues.apache.org/jira/browse/QPID-8483
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.5
>
>
> The operational logs subject used for reporting session operational logs has
> the following format:
> {noformat}
> con:{0}({1}@{2}/{3})/ch:{4}.
> where
> 0 - Connection ID
> 1 - User ID
> 2 - IP
> 3 - Virtualhost
> 4 - Channel ID
> {noformat}
> It can be changed to report a session name. At the moment, the model session
> name is derived from a session ID. After implementation of QPID-8482, the
> AMQP 0-10 session name will be derived from the session name provided by the
> client. That would allow to find the session logs using given session name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8483) [Broker-J] Change session operational log subject to have a session name in it
[
https://issues.apache.org/jira/browse/QPID-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8483:
-
Fix Version/s: qpid-java-broker-8.0.5
> [Broker-J] Change session operational log subject to have a session name in it
> --
>
> Key: QPID-8483
> URL: https://issues.apache.org/jira/browse/QPID-8483
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.5
>
>
> The operational logs subject used for reporting session operational logs has
> the following format:
> {noformat}
> con:{0}({1}@{2}/{3})/ch:{4}.
> where
> 0 - Connection ID
> 1 - User ID
> 2 - IP
> 3 - Virtualhost
> 4 - Channel ID
> {noformat}
> It can be changed to report a session name. At the moment, the model session
> name is derived from a session ID. After implementation of QPID-8482, the
> AMQP 0-10 session name will be derived from the session name provided by the
> client. That would allow to find the session logs using given session name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8483) [Broker-J] Change session operational log subject to have a session name in it
[
https://issues.apache.org/jira/browse/QPID-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8483:
-
Component/s: Broker-J
> [Broker-J] Change session operational log subject to have a session name in it
> --
>
> Key: QPID-8483
> URL: https://issues.apache.org/jira/browse/QPID-8483
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Alex Rudyy
>Priority: Major
>
> The operational logs subject used for reporting session operational logs has
> the following format:
> {noformat}
> con:{0}({1}@{2}/{3})/ch:{4}.
> where
> 0 - Connection ID
> 1 - User ID
> 2 - IP
> 3 - Virtualhost
> 4 - Channel ID
> {noformat}
> It can be changed to report a session name. At the moment, the model session
> name is derived from a session ID. After implementation of QPID-8482, the
> AMQP 0-10 session name will be derived from the session name provided by the
> client. That would allow to find the session logs using given session name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8537) [Broker-J] Replace use of constructors marked deprecated for-removal
[ https://issues.apache.org/jira/browse/QPID-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8537: - Summary: [Broker-J] Replace use of constructors marked deprecated for-removal (was: replace use of constructors marked deprecated for-removal) > [Broker-J] Replace use of constructors marked deprecated for-removal > > > Key: QPID-8537 > URL: https://issues.apache.org/jira/browse/QPID-8537 > Project: Qpid > Issue Type: Task > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.4 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: qpid-java-broker-8.0.5 > > > The Long/Float/Double etc constructors were deprecated in Java 9. Various > bits of the codebase (mostly tests, but some not) are still using these. The > constructors remain available currently, but their deprecation was raised to > for-removal status in Java 16, meaning they are intended for actual removal > at some point. The valueOf methods should be used instead. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8529) [Broker-J] NPE when trying to access digestCrecentials in the cached mode
[ https://issues.apache.org/jira/browse/QPID-8529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8529: - Summary: [Broker-J] NPE when trying to access digestCrecentials in the cached mode (was: NPE when trying to access digestCrecentials in the cached mode) > [Broker-J] NPE when trying to access digestCrecentials in the cached mode > - > > Key: QPID-8529 > URL: https://issues.apache.org/jira/browse/QPID-8529 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.4 >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.5 > > > There is a NPE thrown when trying to digest the credentials from the cache. > Below is the stack trace > 2021-05-21T13:58:19,703Z WARN [qtp1216638014-207] (o.e.j.s.HttpChannel) - > /2021-05-21T13:58:19,703Z WARN [qtp1216638014-207] (o.e.j.s.HttpChannel) - > /java.lang.NullPointerException: null at > org.apache.qpid.server.security.auth.manager.AuthenticationResultCacher.digestCredentials(AuthenticationResultCacher.java:118) > at > org.apache.qpid.server.security.auth.manager.AuthenticationResultCacher.getOrLoad(AuthenticationResultCacher.java:82) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8526) [Broker-J] Connection looping in NonBlockingConnectionTLSDelegate.doWrite()
[
https://issues.apache.org/jira/browse/QPID-8526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8526:
-
Summary: [Broker-J] Connection looping in
NonBlockingConnectionTLSDelegate.doWrite() (was: Connection looping in
NonBlockingConnectionTLSDelegate.doWrite())
> [Broker-J] Connection looping in NonBlockingConnectionTLSDelegate.doWrite()
> ---
>
> Key: QPID-8526
> URL: https://issues.apache.org/jira/browse/QPID-8526
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.4
>Reporter: Daniil Kirilyuk
>Priority: Minor
> Fix For: qpid-java-broker-8.0.5
>
>
> Issue is similar to QPID-8489: on certain conditions SSL connection thread
> falls into an infinite loop consuming CPU.
> Stacktrace from the threaddump:
> {noformat}
> IO-/127.0.0.1:50414 #32 prio=5 os_prio=0 cpu=43504522.88ms
> elapsed=330519.20s tid=0x7f47a0375000 nid=0x9089 runnable
> [0x7f47956fe000]
>java.lang.Thread.State: RUNNABLE
> at
> sun.security.ssl.TransportContext.getHandshakeStatus(java.base@11.0.7/TransportContext.java:571)
> at
> sun.security.ssl.SSLEngineImpl.getHandshakeStatus(java.base@11.0.7/SSLEngineImpl.java:801)
> - locked 0x7f4b721e7340 (a sun.security.ssl.SSLEngineImpl)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.wrapBufferArray(NonBlockingConnectionTLSDelegate.java:239)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.doWrite(NonBlockingConnectionTLSDelegate.java:164)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWrite(NonBlockingConnection.java:521)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.shutdownFinalWrite(NonBlockingConnection.java:422)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.shutdown(NonBlockingConnection.java:384)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:313)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> at
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:533)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.7/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.7/ThreadPoolExecutor.java:628)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory$$Lambda$64/0x7f47d52bcc40.run(Unknown
> Source)
> at java.lang.Thread.run(java.base@11.0.7/Thread.java:834)
> {noformat}
> Stacktrace 2 from the threaddump:
> {noformat}
> IO-/127.0.0.1:50414 #32 prio=5 os_prio=0 cpu=43536330.84ms
> elapsed=330555.26s tid=0x7f47a0375000 nid=0x9089 runnable
> [0x7f47956fe000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.encryptSSL(QpidByteBufferFactory.java:178)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBuffer.encryptSSL(QpidByteBuffer.java:62)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.wrapBufferArray(NonBlockingConnectionTLSDelegate.java:255)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.doWrite(NonBlockingConnectionTLSDelegate.java:164)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWrite(NonBlockingConnection.java:521)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.shutdownFinalWrite(NonBlockingConnection.java:422)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.shutdown(NonBlockingConnection.java:384)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:313)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> at
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.pr
[jira] [Resolved] (QPID-8518) [Broker-J] Message transfer freezes when session runs out of transfer frames
[ https://issues.apache.org/jira/browse/QPID-8518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8518. -- Resolution: Fixed > [Broker-J] Message transfer freezes when session runs out of transfer frames > > > Key: QPID-8518 > URL: https://issues.apache.org/jira/browse/QPID-8518 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: Marek Laca >Priority: Minor > Labels: Broker, Java, Messages > Fix For: qpid-java-broker-8.0.5 > > > It is stated in AMQP protocol documentation: > _An AMQP connection consists of a full-duplex, reliably ordered sequence of > frames. A frame is the unit of work carried on the wire. Connections have a > negotiated maximum frame size allowing byte streams to be easily defragmented > into complete frame bodies representing the independently parsable units._ > Each session negotiates properties and state that drives the flow of the > frames: > * next-incoming-id > * incoming-window > * next-outgoing-id > * outgoing-window > * remote-incoming-window > * remote-outgoing-window > The capacity of the incoming flow is limited by the maximum frame size and > incoming window. When message size exceeds the capacity of the incoming flow > to broker the transfer freezes. Neither client nor broker tries to negotiate > a new incoming window (I have tested several clients.) The broker is the > receiver and so it is the authority that makes the final decision about > incoming window. Hence, the broker should offer to client a new incoming > window when the capacity is depleted. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8515) [Broker-J] Improve operational logging and log every change to the broker state
[ https://issues.apache.org/jira/browse/QPID-8515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8515. -- Resolution: Fixed > [Broker-J] Improve operational logging and log every change to the broker > state > --- > > Key: QPID-8515 > URL: https://issues.apache.org/jira/browse/QPID-8515 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.4 >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.5 > > > Currently there is a gap in operational logging, where the deletion of access > control groups is not logged. We need to identify any other such gaps and fix > it to log every change happening to the broker state. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8515) [Broker-J] Improve operational logging and log every change to the broker state
[ https://issues.apache.org/jira/browse/QPID-8515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8515: - Summary: [Broker-J] Improve operational logging and log every change to the broker state (was: Improve operational logging and log every change to the broker state) > [Broker-J] Improve operational logging and log every change to the broker > state > --- > > Key: QPID-8515 > URL: https://issues.apache.org/jira/browse/QPID-8515 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.4 >Reporter: Dedeepya >Priority: Major > Fix For: qpid-java-broker-8.0.5 > > > Currently there is a gap in operational logging, where the deletion of access > control groups is not logged. We need to identify any other such gaps and fix > it to log every change happening to the broker state. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8514) [Broker-J] High CPU usage and stucked connections
[
https://issues.apache.org/jira/browse/QPID-8514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8514:
-
Summary: [Broker-J] High CPU usage and stucked connections (was: High CPU
usage and stucked connections)
> [Broker-J] High CPU usage and stucked connections
> -
>
> Key: QPID-8514
> URL: https://issues.apache.org/jira/browse/QPID-8514
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.4
>Reporter: Daniil Kirilyuk
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-8.0.5
>
> Attachments: QPID-8514 - broker-log.zip,
> RingPolicyConcurrencyTest.java, threaddump.zip
>
>
> There were around 600 connections in state CLOSE__WAIT:
> {noformat}
> [prod01@fdmchd log]$ netstat -Ainet | grep 22101 | grep TIME_WAIT | wc -l
> 38
> [prod01@fdmchd log]$ netstat -Ainet | grep 22101 | grep CLOSE_WAIT | wc -l
> 625
> [prod01@fdmchd log]$ netstat -Ainet | grep 22101 | grep -v CLOSE_WAIT | grep
> -V TIME_WAIT | wc -l
> 7
> {noformat}
> CPU usage raises up to 90% and higher.
> Connections couldn't be closed by webgui. Broker log contains message below,
> but connections were not closed.
> {noformat}
> 2021-03-26 15:12:28,474 INFO [Broker-Config] (q.m.c.model_delete) -
> [mng:3hpU+miq(admin@/127.0.0.1:62743)]
> [con:751(TEST@/127.0.0.1:40422/default)] CON-1007 : Connection close
> initiated by operator
> {noformat}
> Thread dumps shows around 49 threads with same stacktrace related to ring
> queue
> {noformat}
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.qpid.server.queue.QueueEntryImpl.addStateChangeListener(QueueEntryImpl.java:674)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.acquireOrSteal(QueueEntryImpl.java:316)
> at
> org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1913)
> at
> org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1863)
> at
> org.apache.qpid.server.queue.RingOverflowPolicyHandler$Handler.checkOverflow(RingOverflowPolicyHandler.java:102)
> at
> org.apache.qpid.server.queue.RingOverflowPolicyHandler$Handler.access$000(RingOverflowPolicyHandler.java:44)
> at
> org.apache.qpid.server.queue.RingOverflowPolicyHandler.checkOverflow(RingOverflowPolicyHandler.java:41)
> at
> org.apache.qpid.server.queue.AbstractQueue.doEnqueue(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.enqueue(AbstractQueue.java:1290)
> at
> org.apache.qpid.server.message.RoutingResult$1.postCommit(RoutingResult.java:135)
> at
> org.apache.qpid.server.txn.AsyncAutoCommitTransaction$3.postCommit(AsyncAutoCommitTransaction.java:309)
> at
> org.apache.qpid.server.txn.AsyncCommand.complete(AsyncCommand.java:84)
> at
> org.apache.qpid.server.protocol.v1_0.StandardReceivingLinkEndpoint.receiveComplete(StandardReceivingLinkEndpoint.java:588)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0.lambda$receivedComplete$5(Session_1_0.java:1343)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0$$Lambda$142/959267941.accept(Unknown
> Source)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0.receivedComplete(Session_1_0.java:1343)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$receivedComplete$11(AMQPConnection_1_0Impl.java:1349)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl$$Lambda$141/1774823837.run(Unknown
> Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receivedComplete(AMQPConnection_1_0Impl.java:1347)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.onReceive(AMQPConnection_1_0Impl.java:1328)
> at
> org.apache.qpid.server.transport.AbstractAMQPConnection.lambda$received$2(AbstractAMQPConnection.java:576)
> at
> org.apache.qpid.server.transport.AbstractAMQPConnection$$Lambda$119/6380061.run(Unknown
> Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.transport.AbstractAMQPConnection.received(AbstractAMQPConnection.java:571)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
> at
> org.apache.qpid.server.tr
[jira] [Resolved] (QPID-8514) High CPU usage and stucked connections
[
https://issues.apache.org/jira/browse/QPID-8514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8514.
--
Resolution: Fixed
> High CPU usage and stucked connections
> --
>
> Key: QPID-8514
> URL: https://issues.apache.org/jira/browse/QPID-8514
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.4
>Reporter: Daniil Kirilyuk
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-8.0.5
>
> Attachments: QPID-8514 - broker-log.zip,
> RingPolicyConcurrencyTest.java, threaddump.zip
>
>
> There were around 600 connections in state CLOSE__WAIT:
> {noformat}
> [prod01@fdmchd log]$ netstat -Ainet | grep 22101 | grep TIME_WAIT | wc -l
> 38
> [prod01@fdmchd log]$ netstat -Ainet | grep 22101 | grep CLOSE_WAIT | wc -l
> 625
> [prod01@fdmchd log]$ netstat -Ainet | grep 22101 | grep -v CLOSE_WAIT | grep
> -V TIME_WAIT | wc -l
> 7
> {noformat}
> CPU usage raises up to 90% and higher.
> Connections couldn't be closed by webgui. Broker log contains message below,
> but connections were not closed.
> {noformat}
> 2021-03-26 15:12:28,474 INFO [Broker-Config] (q.m.c.model_delete) -
> [mng:3hpU+miq(admin@/127.0.0.1:62743)]
> [con:751(TEST@/127.0.0.1:40422/default)] CON-1007 : Connection close
> initiated by operator
> {noformat}
> Thread dumps shows around 49 threads with same stacktrace related to ring
> queue
> {noformat}
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.qpid.server.queue.QueueEntryImpl.addStateChangeListener(QueueEntryImpl.java:674)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.acquireOrSteal(QueueEntryImpl.java:316)
> at
> org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1913)
> at
> org.apache.qpid.server.queue.AbstractQueue.deleteEntry(AbstractQueue.java:1863)
> at
> org.apache.qpid.server.queue.RingOverflowPolicyHandler$Handler.checkOverflow(RingOverflowPolicyHandler.java:102)
> at
> org.apache.qpid.server.queue.RingOverflowPolicyHandler$Handler.access$000(RingOverflowPolicyHandler.java:44)
> at
> org.apache.qpid.server.queue.RingOverflowPolicyHandler.checkOverflow(RingOverflowPolicyHandler.java:41)
> at
> org.apache.qpid.server.queue.AbstractQueue.doEnqueue(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.enqueue(AbstractQueue.java:1290)
> at
> org.apache.qpid.server.message.RoutingResult$1.postCommit(RoutingResult.java:135)
> at
> org.apache.qpid.server.txn.AsyncAutoCommitTransaction$3.postCommit(AsyncAutoCommitTransaction.java:309)
> at
> org.apache.qpid.server.txn.AsyncCommand.complete(AsyncCommand.java:84)
> at
> org.apache.qpid.server.protocol.v1_0.StandardReceivingLinkEndpoint.receiveComplete(StandardReceivingLinkEndpoint.java:588)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0.lambda$receivedComplete$5(Session_1_0.java:1343)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0$$Lambda$142/959267941.accept(Unknown
> Source)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> org.apache.qpid.server.protocol.v1_0.Session_1_0.receivedComplete(Session_1_0.java:1343)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.lambda$receivedComplete$11(AMQPConnection_1_0Impl.java:1349)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl$$Lambda$141/1774823837.run(Unknown
> Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.receivedComplete(AMQPConnection_1_0Impl.java:1347)
> at
> org.apache.qpid.server.protocol.v1_0.AMQPConnection_1_0Impl.onReceive(AMQPConnection_1_0Impl.java:1328)
> at
> org.apache.qpid.server.transport.AbstractAMQPConnection.lambda$received$2(AbstractAMQPConnection.java:576)
> at
> org.apache.qpid.server.transport.AbstractAMQPConnection$$Lambda$119/6380061.run(Unknown
> Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.transport.AbstractAMQPConnection.received(AbstractAMQPConnection.java:571)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:611)
> at
> org.apache
[jira] [Resolved] (QPID-8511) [Broker-J] Upgrade dojotoolkit to version 1.16.3
[
https://issues.apache.org/jira/browse/QPID-8511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8511.
--
Resolution: Fixed
> [Broker-J] Upgrade dojotoolkit to version 1.16.3
>
>
> Key: QPID-8511
> URL: https://issues.apache.org/jira/browse/QPID-8511
> Project: Qpid
> Issue Type: Task
> Components: Broker-J
> Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-8.0.5
>
>
> A security vulnerability
> [CVE-2020-5258|https://nvd.nist.gov/vuln/detail/CVE-2020-5258] is reported
> against dojo-toolkit version 1.16.0.
> {quote}
> A deepCopy method is vulnerable to Prototype Pollution. Prototype Pollution
> refers to the ability to inject properties into existing JavaScript language
> construct prototypes, such as objects. An attacker manipulates these
> attributes to overwrite, or pollute, a JavaScript application object
> prototype of the base object by injecting other values.
> {quote}
> Even when vulnerability attack is successful and UI is affected by the
> injected code, it is not expected that it would have any bearing on Qpid REST
> API and messaging functionality.
> In order to prevent various scanning tools from flagging the issue, we need
> to upgrade dojotollkit to version 1.16.3
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8519) Improve broker logs for SSL handshake failure caused by invalid SNI
[ https://issues.apache.org/jira/browse/QPID-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362613#comment-17362613 ] Alex Rudyy commented on QPID-8519: -- Descoped from 8.0.5 > Improve broker logs for SSL handshake failure caused by invalid SNI > --- > > Key: QPID-8519 > URL: https://issues.apache.org/jira/browse/QPID-8519 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.4 >Reporter: Dedeepya >Priority: Major > > During the SSL handshake, if sni header is set to a invalid string, it result > in a SSL handshake failure. However this is logged as a info log on the > broker logs. This can be improved to add operational logs for invalid SNI. > Info log : > 2021-03-12T08:30:14,401Z INFO [IO-/10.161.230.90:51553] > (o.a.q.s.t.NonBlockingConnection) - Exception performing I/O for connection > '/10.161.230.90:51553' : Failed to create SNIHostName from string 'Test_Dev' > Debug log trace: > 2021-03-11 20:36:55,355 DEBUG [IO-/10.161.230.90:52006] > (o.a.q.s.t.NonBlockingConnection) - Exception performing I/O for connection > '/10.161.230.90:52006' > org.apache.qpid.server.util.ConnectionScopedRuntimeException: Failed to > create SNIHostName from string 'Test_Dev' > at > org.apache.qpid.server.transport.network.security.ssl.SSLUtil.createSNIHostName(SSLUtil.java:1077) > at > org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:105) > at > org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496) > at > org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270) > at > org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134) > at > org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97) > at > org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:533) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII > characters > at java.net.IDN.toASCIIInternal(IDN.java:296) > at java.net.IDN.toASCII(IDN.java:122) > at javax.net.ssl.SNIHostName.(SNIHostName.java:99) > at > org.apache.qpid.server.transport.network.security.ssl.SSLUtil.createSNIHostName(SSLUtil.java:1073) > ... 12 common frames omitted -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8519) Improve broker logs for SSL handshake failure caused by invalid SNI
[ https://issues.apache.org/jira/browse/QPID-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8519: - Docs Text: Descoped from 8.0.4 Fix Version/s: (was: qpid-java-broker-8.0.5) > Improve broker logs for SSL handshake failure caused by invalid SNI > --- > > Key: QPID-8519 > URL: https://issues.apache.org/jira/browse/QPID-8519 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.4 >Reporter: Dedeepya >Priority: Major > > During the SSL handshake, if sni header is set to a invalid string, it result > in a SSL handshake failure. However this is logged as a info log on the > broker logs. This can be improved to add operational logs for invalid SNI. > Info log : > 2021-03-12T08:30:14,401Z INFO [IO-/10.161.230.90:51553] > (o.a.q.s.t.NonBlockingConnection) - Exception performing I/O for connection > '/10.161.230.90:51553' : Failed to create SNIHostName from string 'Test_Dev' > Debug log trace: > 2021-03-11 20:36:55,355 DEBUG [IO-/10.161.230.90:52006] > (o.a.q.s.t.NonBlockingConnection) - Exception performing I/O for connection > '/10.161.230.90:52006' > org.apache.qpid.server.util.ConnectionScopedRuntimeException: Failed to > create SNIHostName from string 'Test_Dev' > at > org.apache.qpid.server.transport.network.security.ssl.SSLUtil.createSNIHostName(SSLUtil.java:1077) > at > org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:105) > at > org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496) > at > org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270) > at > org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134) > at > org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97) > at > org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:533) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII > characters > at java.net.IDN.toASCIIInternal(IDN.java:296) > at java.net.IDN.toASCII(IDN.java:122) > at javax.net.ssl.SNIHostName.(SNIHostName.java:99) > at > org.apache.qpid.server.transport.network.security.ssl.SSLUtil.createSNIHostName(SSLUtil.java:1073) > ... 12 common frames omitted -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8519) Improve broker logs for SSL handshake failure caused by invalid SNI
[ https://issues.apache.org/jira/browse/QPID-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-8519: - Docs Text: (was: Descoped from 8.0.4) > Improve broker logs for SSL handshake failure caused by invalid SNI > --- > > Key: QPID-8519 > URL: https://issues.apache.org/jira/browse/QPID-8519 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-8.0.4 >Reporter: Dedeepya >Priority: Major > > During the SSL handshake, if sni header is set to a invalid string, it result > in a SSL handshake failure. However this is logged as a info log on the > broker logs. This can be improved to add operational logs for invalid SNI. > Info log : > 2021-03-12T08:30:14,401Z INFO [IO-/10.161.230.90:51553] > (o.a.q.s.t.NonBlockingConnection) - Exception performing I/O for connection > '/10.161.230.90:51553' : Failed to create SNIHostName from string 'Test_Dev' > Debug log trace: > 2021-03-11 20:36:55,355 DEBUG [IO-/10.161.230.90:52006] > (o.a.q.s.t.NonBlockingConnection) - Exception performing I/O for connection > '/10.161.230.90:52006' > org.apache.qpid.server.util.ConnectionScopedRuntimeException: Failed to > create SNIHostName from string 'Test_Dev' > at > org.apache.qpid.server.transport.network.security.ssl.SSLUtil.createSNIHostName(SSLUtil.java:1077) > at > org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.processData(NonBlockingConnectionTLSDelegate.java:105) > at > org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496) > at > org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270) > at > org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134) > at > org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97) > at > org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:533) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII > characters > at java.net.IDN.toASCIIInternal(IDN.java:296) > at java.net.IDN.toASCII(IDN.java:122) > at javax.net.ssl.SNIHostName.(SNIHostName.java:99) > at > org.apache.qpid.server.transport.network.security.ssl.SSLUtil.createSNIHostName(SSLUtil.java:1073) > ... 12 common frames omitted -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8525) [Broker-J] An attempt to add a duplicate member or group into group provider of type GroupFile results in a removal of existing member or group from a file where data is
[ https://issues.apache.org/jira/browse/QPID-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8525. -- Resolution: Fixed > [Broker-J] An attempt to add a duplicate member or group into group provider > of type GroupFile results in a removal of existing member or group from a > file where data is stored > > > Key: QPID-8525 > URL: https://issues.apache.org/jira/browse/QPID-8525 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.5 > > > An attempt to add a duplicate member or group into group provider of type > GroupFile results in a removal of existing member or group from a file where > data is stored. The effect of removal is detected on the next broker start-up > as corresponding member or group is no longer available. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8526) Connection looping in NonBlockingConnectionTLSDelegate.doWrite()
[
https://issues.apache.org/jira/browse/QPID-8526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8526.
--
Resolution: Fixed
> Connection looping in NonBlockingConnectionTLSDelegate.doWrite()
>
>
> Key: QPID-8526
> URL: https://issues.apache.org/jira/browse/QPID-8526
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.4
>Reporter: Daniil Kirilyuk
>Priority: Minor
> Fix For: qpid-java-broker-8.0.5
>
>
> Issue is similar to QPID-8489: on certain conditions SSL connection thread
> falls into an infinite loop consuming CPU.
> Stacktrace from the threaddump:
> {noformat}
> IO-/127.0.0.1:50414 #32 prio=5 os_prio=0 cpu=43504522.88ms
> elapsed=330519.20s tid=0x7f47a0375000 nid=0x9089 runnable
> [0x7f47956fe000]
>java.lang.Thread.State: RUNNABLE
> at
> sun.security.ssl.TransportContext.getHandshakeStatus(java.base@11.0.7/TransportContext.java:571)
> at
> sun.security.ssl.SSLEngineImpl.getHandshakeStatus(java.base@11.0.7/SSLEngineImpl.java:801)
> - locked 0x7f4b721e7340 (a sun.security.ssl.SSLEngineImpl)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.wrapBufferArray(NonBlockingConnectionTLSDelegate.java:239)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.doWrite(NonBlockingConnectionTLSDelegate.java:164)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWrite(NonBlockingConnection.java:521)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.shutdownFinalWrite(NonBlockingConnection.java:422)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.shutdown(NonBlockingConnection.java:384)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:313)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> at
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:533)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.7/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.7/ThreadPoolExecutor.java:628)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory$$Lambda$64/0x7f47d52bcc40.run(Unknown
> Source)
> at java.lang.Thread.run(java.base@11.0.7/Thread.java:834)
> {noformat}
> Stacktrace 2 from the threaddump:
> {noformat}
> IO-/127.0.0.1:50414 #32 prio=5 os_prio=0 cpu=43536330.84ms
> elapsed=330555.26s tid=0x7f47a0375000 nid=0x9089 runnable
> [0x7f47956fe000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.encryptSSL(QpidByteBufferFactory.java:178)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBuffer.encryptSSL(QpidByteBuffer.java:62)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.wrapBufferArray(NonBlockingConnectionTLSDelegate.java:255)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionTLSDelegate.doWrite(NonBlockingConnectionTLSDelegate.java:164)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWrite(NonBlockingConnection.java:521)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.shutdownFinalWrite(NonBlockingConnection.java:422)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.shutdown(NonBlockingConnection.java:384)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:313)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
> at
> org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575)
> at
> org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366)
>
