[GitHub] activemq-artemis pull request #2377: ARTEMIS-2133 Artemis tab not showing on...
Github user gaohoward commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2377#discussion_r226144345
--- Diff:
artemis-hawtio/artemis-plugin/src/main/webapp/plugin/js/artemisPlugin.js ---
@@ -362,7 +362,7 @@ var ARTEMIS = (function(ARTEMIS) {
workspace.subLevelTabs = subLevelTabs;
- preLogoutTasks.addTask("clearArtemisCredentials", () => {
--- End diff --
surprisingly yes. :)
---
Re: [discussion] About blocking producers
This sounds like one way to do it. Most users need secured brokers and they can adopt this method. Thanks On Wed, Oct 17, 2018 at 1:59 PM michael.andre.pearce wrote: > Because our brokers are fully secured, if we need to stop incoming > messages we simply remove the produce authorisation for users using > security settings. > This seems to work. Is this maybe an option for you? > > > Sent from my Samsung Galaxy smartphone. > Original message From: Howard Gao > Date: 17/10/2018 04:02 (GMT+01:00) To: dev@activemq.apache.org Subject: > Re: [discussion] About blocking producers > Thanks Gary, you are quite right. This seems not a simple problem as I > think is. The pause/resume is even harder to implement. > > And also the credit thing, some client support it (but may or may not use > it), some are totally without it (like mqtt and stomp). > > Howard > > On Tue, Oct 16, 2018 at 6:57 PM Gary Tully wrote: > > > There may be two different use cases here; > > 1) the pause/resume use case, where it makes some sense to leave > producers > > active stop reading/deny credit/buffer etc; the corollary to the pause > > consumers > > 2) the take down for maintenance case, where it would be nice to drain > the > > broker. > > In the past, users have tackled the "maintenance" use case with > > separate acceptors, one for producers and one for consumers. with the > > ability to disable an acceptor via a management operation. That is not > > ideal b/c it requires cooperation with the applications to use the > correct > > acceptors etc. > >However it is a coarse grained option that is a step to shutdown, a > one > > way step that won't be undone via resume. That can more easily be > > implemented with a management op that kills off producers and blocks all > > send operations with some deny interceptor (along the lines of the > > authorisation interceptors). something like shutdownSenders > > > > If the use case is more like shutdownSenders keeping it coarse (on or off > > for the entire server) will be best. > > > > For the pause/resume case it gets tricky; > > - for example if the same connection is used for producing and > consuming, > > any exception can be fatal for the connection, causing retries etc and > > looping. > > - blocking will only work for sync send operations and async operations > > may accumulate. It may require protocol specific smarts. > > - same for of credit, only where flow control is respected by the > client. > > > > I guess my point is that pause/resume may not be the way to go if the use > > case is actually shut down for maintenance. > > > > > > On Tue, 16 Oct 2018 at 04:19 Howard Gao wrote: > > > > > Hi guys, > > > > > > I'm working on this story and I'd like to hear your thoughts. > > > > > > The Jira: https://issues.apache.org/jira/browse/ARTEMIS-2097 > > > > > > This is to provide a functionality of the broker to block on producers > so > > > that user can consume all the existing messages (for maintaining their > > > servers for example), regardless of how the address setting's address > > full > > > policy is configured. The unblock > > > functionality should also be provided to complete this feature. > > > > > > Here is my current implementation: > > > https://github.com/apache/activemq-artemis/pull/2371 > > > > > > The idea is to keep a list of blocked/unblock addresses set by the > user. > > > Any incoming messages will be checked against the list and if its > address > > > is blocked, it will be rejected and an exception will be thrown to the > > > clients. It works for all types of clients (core, openwire, jms, mqtt > > > etc). > > > > > > Any comments are welcome. > > > > > > Thanks > > > Howard > > > > > >
[GitHub] activemq-artemis pull request #2362: ARTEMIS-2117 Add custom LVQ Key and Non...
Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2362 ---
[GitHub] activemq-artemis issue #2362: ARTEMIS-2117 Add custom LVQ Key and Non Destru...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2362 I will merge this now.. if there's any issues we can review later ---
[GitHub] activemq-artemis issue #2375: NO-JIRA small fix to avoid re-distributor bein...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2375 I think this needs a JIRA.. perhaps even a test? ---
[GitHub] activemq-artemis pull request #2377: ARTEMIS-2133 Artemis tab not showing on...
Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2377 ---
[GitHub] activemq-artemis pull request #2378: ARTEMIS-2131 Error compacting journal
Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2378 ---
[GitHub] activemq-artemis pull request #:
Github user michaelandrepearce commented on the pull request: https://github.com/apache/activemq-artemis/commit/48d8a54135732b2b34251f571aa3a5cadc44d3a9#commitcomment-30947903 In artemis-protocols/artemis-amqp-protocol/src/test/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessageTest.java: In artemis-protocols/artemis-amqp-protocol/src/test/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessageTest.java on line 178: Ah cool i see :) nice. ---
[GitHub] activemq-artemis pull request #:
Github user clebertsuconic commented on the pull request: https://github.com/apache/activemq-artemis/commit/48d8a54135732b2b34251f571aa3a5cadc44d3a9#commitcomment-30947882 In artemis-protocols/artemis-amqp-protocol/src/test/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessageTest.java: In artemis-protocols/artemis-amqp-protocol/src/test/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessageTest.java on line 178: Thatâs correct it does not apply to master. Tim Bish âs refactoring on amqp message fixed it. No need for a fix. ---
[GitHub] activemq-artemis pull request #:
Github user michaelandrepearce commented on the pull request: https://github.com/apache/activemq-artemis/commit/48d8a54135732b2b34251f571aa3a5cadc44d3a9#commitcomment-30947762 In artemis-protocols/artemis-amqp-protocol/src/test/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessageTest.java: In artemis-protocols/artemis-amqp-protocol/src/test/java/org/apache/activemq/artemis/protocol/amqp/broker/AMQPMessageTest.java on line 178: @clebertsuconic is there a fix added for this, i notice on the 2.6x branch you made a change to AMQPMessage but not on the commit to master? ---
[GitHub] activemq-artemis issue #2362: ARTEMIS-2117 Add custom LVQ Key and Non Destru...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2362 @michaelandrepearce I tested directly at your branch.. I just rebased on a new branch and ran it and it passed fine. There was a few fixes that you were behind I assume. I will merge it. ---
[GitHub] activemq-artemis issue #2250: ARTEMIS-1996 MappedSequentialFileFactory may c...
Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2250 Can you rebase this? lots of commits since you sent this. I will merge it along with the other PR on the journal. ---
[GitHub] activemq-artemis pull request #2377: ARTEMIS-2133 Artemis tab not showing on...
Github user clebertsuconic commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2377#discussion_r225992639
--- Diff:
artemis-hawtio/artemis-plugin/src/main/webapp/plugin/js/artemisPlugin.js ---
@@ -362,7 +362,7 @@ var ARTEMIS = (function(ARTEMIS) {
workspace.subLevelTabs = subLevelTabs;
- preLogoutTasks.addTask("clearArtemisCredentials", () => {
--- End diff --
This will be enough to fix IE?
---
Re: [discussion] About blocking producers
Or simpler pause (block|fail) as an argument. And resume. Protocol specific flow control is already an issue and could be treated differently. This would be just an extension of what’s already implement and not very extensive to insolent. On Wed, Oct 17, 2018 at 9:05 AM Clebert Suconic wrote: > I propose we add two separate options. > > > - Pause flow control > > That is. We should treat the address as full and all credits wouldn’t be > send until you resume. > > - deny producing > > The addrsss would be in fail mode until you hit resume. > > > All semantics from fail and block flow control would apply as now. > > > > This is easy to implement and the user would select the appropriate > operation as he wishes. > > On Wed, Oct 17, 2018 at 1:59 AM michael.andre.pearce > wrote: > >> Because our brokers are fully secured, if we need to stop incoming >> messages we simply remove the produce authorisation for users using >> security settings. >> This seems to work. Is this maybe an option for you? >> >> >> Sent from my Samsung Galaxy smartphone. >> Original message From: Howard Gao >> Date: 17/10/2018 04:02 (GMT+01:00) To: dev@activemq.apache.org >> Subject: Re: [discussion] About blocking producers >> Thanks Gary, you are quite right. This seems not a simple problem as I >> think is. The pause/resume is even harder to implement. >> >> And also the credit thing, some client support it (but may or may not use >> it), some are totally without it (like mqtt and stomp). >> >> Howard >> >> On Tue, Oct 16, 2018 at 6:57 PM Gary Tully wrote: >> >> > There may be two different use cases here; >> > 1) the pause/resume use case, where it makes some sense to leave >> producers >> > active stop reading/deny credit/buffer etc; the corollary to the pause >> > consumers >> > 2) the take down for maintenance case, where it would be nice to drain >> the >> > broker. >> > In the past, users have tackled the "maintenance" use case with >> > separate acceptors, one for producers and one for consumers. with the >> > ability to disable an acceptor via a management operation. That is not >> > ideal b/c it requires cooperation with the applications to use the >> correct >> > acceptors etc. >> >However it is a coarse grained option that is a step to shutdown, a >> one >> > way step that won't be undone via resume. That can more easily be >> > implemented with a management op that kills off producers and blocks all >> > send operations with some deny interceptor (along the lines of the >> > authorisation interceptors). something like shutdownSenders >> > >> > If the use case is more like shutdownSenders keeping it coarse (on or >> off >> > for the entire server) will be best. >> > >> > For the pause/resume case it gets tricky; >> > - for example if the same connection is used for producing and >> consuming, >> > any exception can be fatal for the connection, causing retries etc and >> > looping. >> > - blocking will only work for sync send operations and async operations >> > may accumulate. It may require protocol specific smarts. >> > - same for of credit, only where flow control is respected by the >> client. >> > >> > I guess my point is that pause/resume may not be the way to go if the >> use >> > case is actually shut down for maintenance. >> > >> > >> > On Tue, 16 Oct 2018 at 04:19 Howard Gao wrote: >> > >> > > Hi guys, >> > > >> > > I'm working on this story and I'd like to hear your thoughts. >> > > >> > > The Jira: https://issues.apache.org/jira/browse/ARTEMIS-2097 >> > > >> > > This is to provide a functionality of the broker to block on >> producers so >> > > that user can consume all the existing messages (for maintaining their >> > > servers for example), regardless of how the address setting's address >> > full >> > > policy is configured. The unblock >> > > functionality should also be provided to complete this feature. >> > > >> > > Here is my current implementation: >> > > https://github.com/apache/activemq-artemis/pull/2371 >> > > >> > > The idea is to keep a list of blocked/unblock addresses set by the >> user. >> > > Any incoming messages will be checked against the list and if its >> address >> > > is blocked, it will be rejected and an exception will be thrown to the >> > > clients. It works for all types of clients (core, openwire, jms, mqtt >> > > etc). >> > > >> > > Any comments are welcome. >> > > >> > > Thanks >> > > Howard >> > > >> > >> > -- > Clebert Suconic > -- Clebert Suconic
[GitHub] activemq-artemis pull request #2378: ARTEMIS-2131 Error compacting journal
GitHub user franz1981 opened a pull request: https://github.com/apache/activemq-artemis/pull/2378 ARTEMIS-2131 Error compacting journal Compaction cannot free a sliced view of a ByteBuffer on Java >=9: the fix is using the original ByteBuffer instead of the slice to perform a file write and allow it to be correctly released by the Cleaner. You can merge this pull request into a Git repository by running: $ git pull https://github.com/franz1981/activemq-artemis ARTEMIS-2131 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2378.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2378 commit 28b75486c7ffa881452bc636e233b71fc5567708 Author: Francesco Nigro Date: 2018-10-17T13:10:04Z ARTEMIS-2131 Error compacting journal Compaction cannot free a sliced view of a ByteBuffer on Java >=9: the fix is using the original ByteBuffer instead of the slice to perform a file write and allow it to be correctly released by the Cleaner. ---
Re: [discussion] About blocking producers
I propose we add two separate options. - Pause flow control That is. We should treat the address as full and all credits wouldn’t be send until you resume. - deny producing The addrsss would be in fail mode until you hit resume. All semantics from fail and block flow control would apply as now. This is easy to implement and the user would select the appropriate operation as he wishes. On Wed, Oct 17, 2018 at 1:59 AM michael.andre.pearce wrote: > Because our brokers are fully secured, if we need to stop incoming > messages we simply remove the produce authorisation for users using > security settings. > This seems to work. Is this maybe an option for you? > > > Sent from my Samsung Galaxy smartphone. > Original message From: Howard Gao > Date: 17/10/2018 04:02 (GMT+01:00) To: dev@activemq.apache.org Subject: > Re: [discussion] About blocking producers > Thanks Gary, you are quite right. This seems not a simple problem as I > think is. The pause/resume is even harder to implement. > > And also the credit thing, some client support it (but may or may not use > it), some are totally without it (like mqtt and stomp). > > Howard > > On Tue, Oct 16, 2018 at 6:57 PM Gary Tully wrote: > > > There may be two different use cases here; > > 1) the pause/resume use case, where it makes some sense to leave > producers > > active stop reading/deny credit/buffer etc; the corollary to the pause > > consumers > > 2) the take down for maintenance case, where it would be nice to drain > the > > broker. > > In the past, users have tackled the "maintenance" use case with > > separate acceptors, one for producers and one for consumers. with the > > ability to disable an acceptor via a management operation. That is not > > ideal b/c it requires cooperation with the applications to use the > correct > > acceptors etc. > >However it is a coarse grained option that is a step to shutdown, a > one > > way step that won't be undone via resume. That can more easily be > > implemented with a management op that kills off producers and blocks all > > send operations with some deny interceptor (along the lines of the > > authorisation interceptors). something like shutdownSenders > > > > If the use case is more like shutdownSenders keeping it coarse (on or off > > for the entire server) will be best. > > > > For the pause/resume case it gets tricky; > > - for example if the same connection is used for producing and > consuming, > > any exception can be fatal for the connection, causing retries etc and > > looping. > > - blocking will only work for sync send operations and async operations > > may accumulate. It may require protocol specific smarts. > > - same for of credit, only where flow control is respected by the > client. > > > > I guess my point is that pause/resume may not be the way to go if the use > > case is actually shut down for maintenance. > > > > > > On Tue, 16 Oct 2018 at 04:19 Howard Gao wrote: > > > > > Hi guys, > > > > > > I'm working on this story and I'd like to hear your thoughts. > > > > > > The Jira: https://issues.apache.org/jira/browse/ARTEMIS-2097 > > > > > > This is to provide a functionality of the broker to block on producers > so > > > that user can consume all the existing messages (for maintaining their > > > servers for example), regardless of how the address setting's address > > full > > > policy is configured. The unblock > > > functionality should also be provided to complete this feature. > > > > > > Here is my current implementation: > > > https://github.com/apache/activemq-artemis/pull/2371 > > > > > > The idea is to keep a list of blocked/unblock addresses set by the > user. > > > Any incoming messages will be checked against the list and if its > address > > > is blocked, it will be rejected and an exception will be thrown to the > > > clients. It works for all types of clients (core, openwire, jms, mqtt > > > etc). > > > > > > Any comments are welcome. > > > > > > Thanks > > > Howard > > > > > > -- Clebert Suconic
[GitHub] activemq-artemis pull request #2377: ARTEMIS-2133 Artemis tab not showing on...
GitHub user gaohoward opened a pull request: https://github.com/apache/activemq-artemis/pull/2377 ARTEMIS-2133 Artemis tab not showing on IE browser The web console on IE doesn't have 'Artemis' showed up because it doesn't support javascripts => function. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gaohoward/activemq-artemis a_web_ie Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2377.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2377 commit 7206326c64c7f74da8ae8b2921e784cdfe8b2a4a Author: Howard Gao Date: 2018-10-17T12:15:17Z ARTEMIS-2133 Artemis tab not showing on IE browser The web console on IE doesn't have 'Artemis' showed up because it doesn't support javascripts => function. ---
[GitHub] activemq-artemis pull request #2376: [ARTEMIS-2130]Web console display blank...
GitHub user shailendra14k opened a pull request: https://github.com/apache/activemq-artemis/pull/2376 [ARTEMIS-2130]Web console display blank ClientID for the core client JIRA:- https://issues.apache.org/jira/browse/ARTEMIS-2130 While using core client. Connection.setClientID(String) , set the ServerSession metadata using the key "jms-client-id" You can merge this pull request into a Git repository by running: $ git pull https://github.com/shailendra14k/activemq-artemis ARTEMIS-2130 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2376.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2376 commit a730a2891a4cd846ec2e15ea2cb76313b3975e71 Author: Shailendra Kumar Singh Date: 2018-10-17T10:24:24Z [ARTEMIS-2130]Web console display blank ClientID for the core client ---
Re: Website
On Fri, Oct 12, 2018 at 8:38 PM Bruce Snyder wrote:
> Fair points, Martyn. I like the idea of a combination of JIRA issues plus a
> list of those issues that is easily visible somewhere such as the wiki.
>
> Seeing as how we are moving the website around completely, I believe we
> need to include the docs to support the older versions in some way. So, the
> first thought that came to mind is a search capability in order for users
> to find them easier. Another idea, we could also keep the old site intact
> and available as a sub-domain or URL, e.g., 5x.activemq.apache.org,
> activemq.apache.org/5.x, etc. However, the advantage of a search feature
> is
> that it would be useful across the site, not just for older stuff. We might
> even be able structure the search to allow users to select a version of the
> docs that they would like to search. Anyway, just some thoughts.
>
> I agree that we should try to get the new site functional ASAP, but that
> should not eliminate the old site entirely. We should not abandon users of
> older versions.
>
+1 Bruce.
I had thought that the export of the current site into the gitbook had all
the info, but perhaps there are missing pieces. I like the idea of keeping
the old site running and link to it from the new site. This ensures
existing users have all the info they need, but let's us move forward with
new content. Perhaps we can switch out the exiting home page for the new
one and add a link to old website AMQ project page ("Existing users looking
for the original ActiveMQ website click here."). If we are able to get
some stats on number of accesses to a particular page, we can use that info
to prioritise porting older content.
Search, feature also a good idea, but I'm not sure how much effort would be
involved, there is already a search feature in the gitbook document (linked
to on the project page).
How about we fill in the existing placeholder content and add links to the
old sites from each project page (and the home page)? We could go live
with this? Then start working through the nice to haves/criticals. I
think once we're live and the code is available, the community will be more
inclined to report/fixing issues.
Cheers
>
> Bruce
>
> On Fri, Oct 12, 2018 at 2:44 AM Martyn Taylor wrote:
>
> > Cheers gents, looks like we're all set with the git repos.
> >
> > Shall we start putting together a ToDo list for what needs to happen to
> > move to the new site? JIRA perhaps?
> >
> > Bruce you mentioned a search feature for older content. Can you
> elaborate
> > on this. Also, there's the actual content for the pages, key features,
> > users etc... Perhaps we can all contribute to these? I could take care
> of
> > the Artemis side of things, if people with more experience in NMS, CMS
> and
> > 5.x could come up with some content for the project home pages?
> >
> > I agree with Michael in that it'd be good to get the new site running
> even
> > if it's not 100% perfect then iteratively improve on it.
> >
> > Cheers
> >
> > On Thu, Oct 11, 2018 at 12:56 AM Clebert Suconic <
> > clebert.suco...@gmail.com>
> > wrote:
> >
> > > How to delete one now ?
> > >
> > > On Tue, Oct 9, 2018 at 6:55 PM Bruce Snyder
> > > wrote:
> > >
> > > > Whoops, I just created one as well:
> > > >
> > > > https://gitbox.apache.org/repos/asf?p=activemq-website.git
> > > >
> > > > Bruce
> > > >
> > > > On Tue, Oct 9, 2018 at 8:49 AM Clebert Suconic <
> > > clebert.suco...@gmail.com>
> > > > wrote:
> > > >
> > > > > New repo created:
> > > > >
> > > > > https://gitbox.apache.org/repos/asf?p=activemq-www.git
> > > > > On Tue, Oct 9, 2018 at 10:47 AM Clebert Suconic
> > > > > wrote:
> > > > > >
> > > > > > Robbie Gemmel pointed me to https://gitbox.apache.org/
> > > > > >
> > > > > > I'm trying to create one now:
> > > > > > On Tue, Oct 9, 2018 at 10:36 AM Clebert Suconic
> > > > > > wrote:
> > > > > > >
> > > > > > > That's for Bruce Snyder then...
> > > > > > > On Tue, Oct 9, 2018 at 10:29 AM Justin Bertram <
> > > jbert...@redhat.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > > There's a "Create a new Git repository" option on
> > > > > > > > https://selfserve.apache.org/. I clicked it and logged in,
> > but
> > > > > apparently
> > > > > > > > it's restricted to ASF members and PMC chairs.
> > > > > > > >
> > > > > > > >
> > > > > > > > Justin
> > > > > > > >
> > > > > > > > On Tue, Oct 9, 2018 at 9:24 AM Clebert Suconic <
> > > > > clebert.suco...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I create an Infra JIRA for this:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > https://issues.apache.org/jira/browse/INFRA-17124
> > > > > > > > > On Tue, Oct 9, 2018 at 9:49 AM Clebert Suconic
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > I asked infra and no reponse.
> > > > > > > > > >
> > > > > > > > > > Does anyone know any procedure on creating a repo at
> > apache?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I
[GitHub] activemq-artemis pull request #2373: ARTEMIS-2125 Tabs preference changes to...
Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2373 ---
[GitHub] activemq-artemis issue #2373: ARTEMIS-2125 Tabs preference changes to displa...
Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/2373 @andytaylor thanks!! I will cherry-pick into 2.6-x too :+1: ---
[GitHub] activemq-artemis issue #2373: ARTEMIS-2125 Tabs preference changes to displa...
Github user andytaylor commented on the issue: https://github.com/apache/activemq-artemis/pull/2373 looks good I will merge. ---
[GitHub] activemq-artemis issue #2373: ARTEMIS-2125 Tabs preference changes to displa...
Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2373 Lgtm ---
