[jira] [Created] (ARTEMIS-3739) Buy Guest Post- Value of Guest Post
Guest Post created ARTEMIS-3739: --- Summary: Buy Guest Post- Value of Guest Post Key: ARTEMIS-3739 URL: https://issues.apache.org/jira/browse/ARTEMIS-3739 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Guest Post Anyone involved in Internet marketing or ecommerce of any kind depends on traffic to make money. Without traffic to your website, marketers might as well go back to their day jobs. Fortunately, legitimately driving traffic to your website is not very difficult if you make the occasional guest post. Among the various ways of getting visitors to a website, making a guest post or [*buy guest post*|https://linkerbuzz.com/guest-post-websites-marketplace/] may be one of the most overlooked. Online business owners are good about throwing lots of money at advertising, but often fail to overlook the value of an article posted on the Internet at no cost, except for your time. *Two Facts about Guest Posting* * The fastest way to grow a blog in the entire world is with guest posting. * The hardest way to grow a blog in the entire world is with guest posting. Guest posting is not easy and it requires quite a bit of work. A guest post is an article that is written by a blog author and posted on a different blog. A well-written, informative guest post can drive a lot of traffic to a blogger's website. For the well-written article you must hire professional one. The traffic that you get from guest posting is usually not monumental, but this all depends on the blog. High-traffic blogs usually have stricter editorial guidelines. The stuff has to be good, but the professional guest post service can do this easily for you. *Find a Site* Thanks to goggle's blog search, it isn't hard to find a hundred blogs in your niche. Go with the sites you already know before you start looking for new ones. Trust me, even if the site is huge, as long as they state that they accept guest posts then you should be able to get published there. If you can't write something good enough then you will need to work on it until you can, In that case, You can [*buy guest post*|https://linkerbuzz.com/] on any sites that you want. *Do Your Research* You obviously will need to check out the sites you choose to write for and double check the requirements they have for guest posting. If you don’t know how to do, then why not you find the best guest post service that provide the all information of websites that you want. h2. The Importance of Guest Posts Internet marketing is a rewarding but complicated endeavor. For one thing, it is a relatively recent field. People working in some fields can read about decade’s worth of research related to those fields, while people in the Internet marketing field will be often by learning from people who have been in the business for a relatively brief period of time. The methods they will be using may be well under a decade old, which can make them seem relatively untested. Many of the Internet marketers working in today's field are the ones testing the most highly recommended methods, which are often still in their experimental phases. The Internet marketing landscape also changes fairly rapidly. Search engine optimization, or SEO, once largely involved filling articles with keywords. However, improvements in spam filters and changes in search engine technology have already changed the mechanics of SEO. Today, people working in Internet marketing will have to find creative new ways of conducting SEO. Writing a guest post or *buy guest post* on various popular blogs and websites is becoming increasingly popular. _A guest post is therefore a great option for an Internet marketer._ When it comes to guest posting, people that are getting started on the Internet can more or less use other people's fame and popularity to their advantage. A guest post will be read on a website that already has a strong presence. New bloggers and Internet marketers may be able to get some attention from members of that particular audience. However, popular websites and blogs will already have the advantage when it comes to search engine results h2. Benefits of Guest Posts When you have a website or a blog, using [*guest posting service*|https://linkerbuzz.com/] is a great way to promote your business and website. It offers many benefits both to you and to the person that you are guest posting for and to yourself. *Some of the benefits include:* # *Offers a wide web coverage* Using these services enhances a wide coverage over the internet. It can make you money since with this coverage; you can guest post for other people or even post on other blogs. With this the readers will also easily access your site and articles and this will promote yourself and your business. # *Enhance much advertising* Using guest posting services improves your
[jira] [Created] (ARTEMIS-3738) Buy Guest Post on Nytimes.com
Guest Post created ARTEMIS-3738: --- Summary: Buy Guest Post on Nytimes.com Key: ARTEMIS-3738 URL: https://issues.apache.org/jira/browse/ARTEMIS-3738 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Guest Post h2. What is a high quality website? Over the years the whole SEO industry is talking about the need of producing high quality content and top experts came up with the clever quote ‘Content is king’, meaning that content is the success factor of any website. While this is true, does it mean that a website with good content is also a high quality website? The answer is NO. Good content is not enough. It is one of the factors (the most important) that separates low from high quality sites but good content alone does not complete the puzzle of what is considered by Google as a high quality website. Now you can get the high quality on high quality sites like Nytimes, Forbes etc. You can also buy [nytimes guest Post|https://linkerbuzz.com/guest-post-on-nytimes-com/] at a reasonable price from the best [guest post service|https://linkerbuzz.com/]. h2. What is SEO SEO is short for ‘Search Engine Optimization’. It refers to the process of increasing a websites traffic flow by optimizing several aspects of a website; such as your on-page SEO, technical SEO & off-site SEO,. Your SEO strategy should ideally be planned around your content strategy. For this you will require three elements, 1.) keywords, 2.) links and 3.) substance to piece your content strategy together. Guest Post on High quality sites can improve your SEO ranking. To improve ranking and boost ranking, buy [Guest Post on nytimes|https://linkerbuzz.com/guest-post-on-nytimes-com/] from the high quality guest post service. h2. Characteristics of a high quality website A high quality website has the following characteristics: *Unique content* Content is unique both within the website itself (i.e. each page has unique content and not similar to other pages), but also compared to other websites. *Demonstrate Expertise* Content is produced by experts based on research and or experience. If for example the subject is health related, then the advice should be provided by qualified authors who can professionally give advice for the particular subject. *Unbiased content* Content is detail and describes both sides of a story and is not promoting a single product, idea or service. *Accessibility* A high quality website has versions for non PC users as well. It is important that mobile and tablet users can access the website without any usability issues. *Usability* Can the user navigate the website easily; is the website user friendly? *Attention to detail* Content is easy to read with images (if applicable) and free of spelling and grammar mistakes. Does it seem that the owner cares on what is published on the website or is it for the purpose of having content in order to run ads? *SEO Optimized* Optimizing a web site for search engines has many benefits but it is important not to overdo it. A good quality web site needs to have non-optimized content as well. This is my opinion and although some people may disagree it is a fact that over-optimization can sometimes generate the opposite results. The reason is that algorithms can sometimes interpret over-optimization as an attempt to game the system and they may take measures to prevent this from happening. *Balance between content and ads* It is not something bad for a website to have ads or promotions but these should not distract the users from finding the information they need. *Speed* A high quality website loads fast. A fast website will rank higher and create more conventions, sales and loyal readers. *Social* Social media changed our lives, the way we communicate but also the way we assess quality. It is expected for a good product to have good reviews, Facebook likes and Tweets. Before you make a decision to buy or not, you may examine these social factors as well. Likewise, It is also expected for a good website to be socially accepted and recognized i.e. have Facebook followers, RSS subscribers etc. *User Engagement and Interaction* Do users spend enough time on the site and read more than one pages before they leave? Do they interact with the content by adding comments, making suggestions, getting into conversations etc.? *Better than the competition* When you take a specific keyword, is your website better than your competitors? Does it deserve one of the top positions if judged without bias? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (ARTEMIS-3737) Buy Guest Post on Forbes
Guest Post created ARTEMIS-3737: --- Summary: Buy Guest Post on Forbes Key: ARTEMIS-3737 URL: https://issues.apache.org/jira/browse/ARTEMIS-3737 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Guest Post h2. What is a quality website? We have now a definition by Google of what is a quality site; it is given by a link at bottom. These become even more essential since efforts to filter these sites in search results, depending on their quality. Now it is very easy to rank your content and sites through the high quality sites. There are lots of high quality sites over the internet like Forbes, NYtimes and Hackernoon etc. You can get [Guest Post on Forbes|https://linkerbuzz.com/guest-post-on-forbes-com/] and as well other high quality websites from the best guest post service online. Although the quality of a site has always been an issue it took a particular importance in April 2011 with the Panda Update, the change of the Google algorithm to eliminate poor quality pages that even go far in penalizing an entire site if a portion of its content is not well received by users and get no backlinks. A high quality website will grow over time both in terms of loyal readers but also in terms of search engine trust, which is equivalent to more organic visits. Google engineers are trying for years to make their algorithms clever enough to identify and rank websites that are of good quality. It is not an easy task, taking into account that everything has to be decided by a computer program and not a human. Nevertheless with the introduction of ‘Panda’ a few years ago, it seems that they are in the right path. h2. What are the benefits for guest blogging? African Americans are establishing a business’s online at an accelerating rate. This is the perfect opportunity for black business owners to come together and network their services to one another. Even though our customer base embrace all nations, it is important that blacks establish a strong support system for one another. *That support system will also provide the following:* * A great way to drive traffic and readership to your site or blog * An outstanding opportunity to build your reputation and influence in your target market * An excellent way to build "merit-based" links from relevant sites h2. The Benefits of High Quality Content for SEO In order for your content to be effective and get the required results, people need to be able to find it. Content can simply not be found without good SEO, which includes the use of keywords, internal & external links, alt text and more. So, what exactly are the benefits? * Content can be found easily * Good rank positions * Improved site score * Improved website usability * Improved user experience * Reaching the right target audience This beginner’s guide to SEO content may help you to better understand the topic at hand or here is an info graphic which lists ten steps needed to generate the right kind of content and increase its impact. You can [buy guest post|https://linkerbuzz.com/] on High Quality Websites. High quality content is what attracts users to your website, it gets them talking about and engaging with your brand. [Forbes guest Post|https://linkerbuzz.com/guest-post-on-forbes-com/] has high quality content. It increases the value of those links and can increase your popularity. Content marketing is an effective strategy for both B2C and B2B businesses, as long as you take the time to undertake research and piece together an effective content plan. User’s expectations have been set high and they expect certain content types to be a part of your marketing strategy. Without quality content or an effective content strategy your business will struggle to grow in the digital world. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (ARTEMIS-3736) Benefits of Guest Posting
Guest Post created ARTEMIS-3736: --- Summary: Benefits of Guest Posting Key: ARTEMIS-3736 URL: https://issues.apache.org/jira/browse/ARTEMIS-3736 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Guest Post Writing content that is both search engines friendly and informative for readers can be quite challenging. If you have what it takes to write quality posts, you can use Guest Posting or guest posting to boost your search engine rankings. Guest posting can be an excellent way to earn recognition, build up your brand, and get relevant backlinks to your website. Guest posts are a great way to gain exposure for your company, build trust with your audience, and generate qualified leads. In 2021 you can [*buy guest post*|https://linkerbuzz.com/] instead of writing posts. A guest post is an article written for a blog by someone who is not part of the blog's regular team. Bloggers often publish the posts on their site to generate income from ads or affiliate links, to promote a product or service, or to increase their site traffic. Guest posts may also be referred to as guest content, guest contributions and sponsored posts. If you are looking for a [*guest post service*|https://linkerbuzz.com/] provider, look no further. We provide high-quality posts on business topic at competitive prices. Contact us today to find out more! h2. Benefits of Guest Posting When done properly, a guest blog benefits all parties involved: you, the other site owner, and the readers of both sites. The site owner will have fresh content handed to them on a silver platter, which they didn't have to invent themselves. They get a break from writing, and their readers experience a change as well. The readers themselves benefit by being exposed to a new voice with new ideas. The main benefit to Guest Posting, however, is to you. A good guest post will bring you new readers, increase traffic, and heighten your search engine visibility. *Promote yourself* It's a great way to promote your website. If you have your own blog, you can guest post on other blogs that are on similar topics to yours and make money from your blog with advertising or other products. The links on their website can send you traffic and will help you move up in the search results of search engines like Google or Yahoo. It seems like it's a lot to do without a lot of direct benefit, but it will help you over time. *Promote your Business* Do you have a regular business, online or offline? You can help promote it through guest posting. Guest post on sites that are in your industry niche and link back to your business website. If you don't have a business website, get one right away. You're losing out on a big market! h2. Only write for trustworthy and relevant sites Google hates spammy websites, so it is important for a number of reasons that you only blog for good websites. What is a good website? You can judge a website by its domain rating, design and how user-friendly it is. The website should also be relevant to your topic and business. Avoid associating yourself with poor quality and spammy websites because you could end up being penalized by Google, which certainly isn’t worth it. You shouldn’t want to associate your brand with these types of sites anyway. Gain Popularity and Traffic to [*Submit guest post + Business*|https://linkerbuzz.com/business/]. h2. A Guest Post Builds Quality and Natural Backlinks Search engines consider the number and the quality of links pointing back to your website when they determine your rankings. Therefore, one of the main reasons to guest post is to have additional avenues to obtain more quality and natural backlinks. Many guest posting sites allow you to include at least one link back to your website, which in turn, makes you more discoverable. Guest posting benefits also include the opportunity to get to know other bloggers and webmasters you may not have met otherwise. You’ll start to become more recognizable within your industry, and other people and companies will get the chance to learn about you too. The networking and exposure you can achieve from guest posting often lead to profitable partnerships and collaborations. Guest posting can offer many benefits to your company. By sharing your expertise on other industry websites, you expose your brand to a new audience and boost your SEO at the same time. Not sure where to begin?. Contact us today for more information. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (ARTEMIS-3735) What is guest posting?
Guest Post created ARTEMIS-3735: --- Summary: What is guest posting? Key: ARTEMIS-3735 URL: https://issues.apache.org/jira/browse/ARTEMIS-3735 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Guest Post Guest Posting is a great tool for increasing your exposure, creating credibility and links, sharing your posts and getting new followers and networking with fellow bloggers which directly helps with various aspects of SEO. Guest Post Services are a must have for any company that wants to have a healthy relationship with other industry influencers. [*Guest Post Service*|https://linkerbuzz.com/] can help you build your brand and generate leads. [*Buy guest post*|https://linkerbuzz.com/] to get benefits of guest posting. This is when you submit your content on a like-minded website other than yours. Most people utilize blog posting for 3 things... Credibility- in the Network Marketing community this is big (credibility and branding). If you want higher conversions, income, and sustainability then you must have a hand in guest posting. Traffic- If the website you submit your content to have a lot of traffic then expect to get piece of it. Link Juice- Depending on the ranking and the relativity this can be huge. *Why Is Guest Posting Important* It can help improve your search engine rankings over time. This is the primary reason why you should guest blog to begin with. Quality, relevant backlinks are what ultimately decide where your website ranks. Secondly, you'll get an increase in traffic to your site. Your blog will be exposed to a wider audience of readers. More visitors are never a bad thing, right? Beyond that, however, Guest Posting can also help improve your writing skills. Are you new to the world of blogging? Well, practice makes perfect. The more you write, the better you will become. So why not consider writing for someone else's blog. You'll not only get the benefits of better rank and traffic, but you can also improve as a writer and learn from other bloggers as well. Ultimately, Guest Posting is valued by the search engines because it requires a little more work and effort from the webmaster. You can't simply piece together a poorly written article or use software to automatically submit spun content to thousands of websites. No, this type of promotion requires you to contact another person and get their approval to post your content. It is well worth the effort as it can help improve your site's ranking as part of an overall back linking strategy. *Build brand awareness* Building brand awareness is one of the core values of all marketing strategies. If you think of a fizzy drink, a chocolate bar, or a trainer, the chances are that particular brands immediately pop into your head. This is why building brand awareness is so important. Even if you don’t plan on taking over the world, you want customers and prospects to think of you when talking about products or services in your niche. You want to be recognized as a reliable and high-quality brand, so people automatically gravitate to you when they need a particular product or service that you sell. *Build links to your site* Link building is the process of gaining hyperlinks from other websites back to your own, and there are two fundamental ways that the search engines use links: * To discover new web pages * To help determine how well a page should rank in their results * [*Submit guest post + Automotive*|https://linkerbuzz.com/automotive/] *So, is Guest Posting still worth it?* In short, the answer is yes. There are many benefits of following Guest Posting best practices such as brand awareness, building links and improving your website’s domain authority. Publishing useful content on high quality, relevant websites can benefit your search engine rankings greatly, and ultimately bring more traffic to your site. It will also build your authority in the industry and bring others in your sector to you as a thought leader and expert in your field. This article has hopefully allowed you to understand the benefits of Guest posting! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-2934) ARTEMIS-2226 causes excessive notifications to be sent for Spring XA clients
[ https://issues.apache.org/jira/browse/ARTEMIS-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-2934. Resolution: Fixed > ARTEMIS-2226 causes excessive notifications to be sent for Spring XA clients > > > Key: ARTEMIS-2934 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2934 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.20.0 >Reporter: Anton Roskvist >Priority: Minor > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Hi, > The fix in https://issues.apache.org/jira/browse/ARTEMIS-2226 causes > excessive notifications to be sent for clients running XA transaction through > the Spring framework. > The notifications sent are SESSION_CREATED and SESSION_CLOSED. > I strongly suspect this is because Spring DMLC cannot cache consumers > properly when running XA, causing it to create and remove a new session for > each message processed. > Now I am not arguing that is not bad practice, because it is, but lots of > applications run on top of this logic. I also suspect this might affect more > but not be as pronounced. > > I have been able to prove the aforementioned patch is what causes the issue > by removing: > sendSessionNotification(CoreNotificationType.SESSION_CREATED); > and > sendSessionNotification(CoreNotificationType.SESSION_CLOSED); > from ServerSessionImpl.java (they where added in the patch) > Now I do not fully understand the intent of the original patch but I think it > should be made conditional, that is, send those notifications only for MQTT > session or something similar. > > In the environment I am testing this on the difference is huge as I have a > lot of independent applications all running Spring+XA. About 40% of all > messages getting sent and received are notifications. > > Br, > Anton -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-2934) ARTEMIS-2226 causes excessive notifications to be sent for Spring XA clients
[ https://issues.apache.org/jira/browse/ARTEMIS-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-2934: - Summary: ARTEMIS-2226 causes excessive notifications to be sent for Spring XA clients (was: ARTEMIS-2226 causes excessive notificaions to be sent for Spring XA clients) > ARTEMIS-2226 causes excessive notifications to be sent for Spring XA clients > > > Key: ARTEMIS-2934 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2934 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.20.0 >Reporter: Anton Roskvist >Priority: Minor > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Hi, > The fix in https://issues.apache.org/jira/browse/ARTEMIS-2226 causes > excessive notifications to be sent for clients running XA transaction through > the Spring framework. > The notifications sent are SESSION_CREATED and SESSION_CLOSED. > I strongly suspect this is because Spring DMLC cannot cache consumers > properly when running XA, causing it to create and remove a new session for > each message processed. > Now I am not arguing that is not bad practice, because it is, but lots of > applications run on top of this logic. I also suspect this might affect more > but not be as pronounced. > > I have been able to prove the aforementioned patch is what causes the issue > by removing: > sendSessionNotification(CoreNotificationType.SESSION_CREATED); > and > sendSessionNotification(CoreNotificationType.SESSION_CLOSED); > from ServerSessionImpl.java (they where added in the patch) > Now I do not fully understand the intent of the original patch but I think it > should be made conditional, that is, send those notifications only for MQTT > session or something similar. > > In the environment I am testing this on the difference is huge as I have a > lot of independent applications all running Spring+XA. About 40% of all > messages getting sent and received are notifications. > > Br, > Anton -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-2934) ARTEMIS-2226 causes excessive notifications to be sent for Spring XA clients
[ https://issues.apache.org/jira/browse/ARTEMIS-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-2934: - Issue Type: Bug (was: New Feature) > ARTEMIS-2226 causes excessive notifications to be sent for Spring XA clients > > > Key: ARTEMIS-2934 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2934 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.20.0 >Reporter: Anton Roskvist >Priority: Minor > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Hi, > The fix in https://issues.apache.org/jira/browse/ARTEMIS-2226 causes > excessive notifications to be sent for clients running XA transaction through > the Spring framework. > The notifications sent are SESSION_CREATED and SESSION_CLOSED. > I strongly suspect this is because Spring DMLC cannot cache consumers > properly when running XA, causing it to create and remove a new session for > each message processed. > Now I am not arguing that is not bad practice, because it is, but lots of > applications run on top of this logic. I also suspect this might affect more > but not be as pronounced. > > I have been able to prove the aforementioned patch is what causes the issue > by removing: > sendSessionNotification(CoreNotificationType.SESSION_CREATED); > and > sendSessionNotification(CoreNotificationType.SESSION_CLOSED); > from ServerSessionImpl.java (they where added in the patch) > Now I do not fully understand the intent of the original patch but I think it > should be made conditional, that is, send those notifications only for MQTT > session or something similar. > > In the environment I am testing this on the difference is huge as I have a > lot of independent applications all running Spring+XA. About 40% of all > messages getting sent and received are notifications. > > Br, > Anton -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (ARTEMIS-2934) ARTEMIS-2226 causes excessive notificaions to be sent for Spring XA clients
[ https://issues.apache.org/jira/browse/ARTEMIS-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic reopened ARTEMIS-2934: -- > ARTEMIS-2226 causes excessive notificaions to be sent for Spring XA clients > --- > > Key: ARTEMIS-2934 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2934 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.20.0 >Reporter: Anton Roskvist >Priority: Minor > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Hi, > The fix in https://issues.apache.org/jira/browse/ARTEMIS-2226 causes > excessive notifications to be sent for clients running XA transaction through > the Spring framework. > The notifications sent are SESSION_CREATED and SESSION_CLOSED. > I strongly suspect this is because Spring DMLC cannot cache consumers > properly when running XA, causing it to create and remove a new session for > each message processed. > Now I am not arguing that is not bad practice, because it is, but lots of > applications run on top of this logic. I also suspect this might affect more > but not be as pronounced. > > I have been able to prove the aforementioned patch is what causes the issue > by removing: > sendSessionNotification(CoreNotificationType.SESSION_CREATED); > and > sendSessionNotification(CoreNotificationType.SESSION_CLOSED); > from ServerSessionImpl.java (they where added in the patch) > Now I do not fully understand the intent of the original patch but I think it > should be made conditional, that is, send those notifications only for MQTT > session or something similar. > > In the environment I am testing this on the difference is huge as I have a > lot of independent applications all running Spring+XA. About 40% of all > messages getting sent and received are notifications. > > Br, > Anton -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (ARTEMIS-3720) Max number of messages as a deciding factor for Paging
[ https://issues.apache.org/jira/browse/ARTEMIS-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic reopened ARTEMIS-3720: -- > Max number of messages as a deciding factor for Paging > -- > > Key: ARTEMIS-3720 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3720 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.21.0 > > Time Spent: 9h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3720) Max number of messages as a deciding factor for Paging
[ https://issues.apache.org/jira/browse/ARTEMIS-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3720. Resolution: Fixed > Max number of messages as a deciding factor for Paging > -- > > Key: ARTEMIS-3720 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3720 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.21.0 > > Time Spent: 9h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3720) Max number of messages as a deciding factor for Paging
[ https://issues.apache.org/jira/browse/ARTEMIS-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-3720: - Issue Type: New Feature (was: Improvement) > Max number of messages as a deciding factor for Paging > -- > > Key: ARTEMIS-3720 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3720 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.21.0 > > Time Spent: 9h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-2618) Improve Handling of Shutdown on critical I/O Error
[
https://issues.apache.org/jira/browse/ARTEMIS-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic updated ARTEMIS-2618:
-
Fix Version/s: 2.22.0
(was: 2.21.0)
> Improve Handling of Shutdown on critical I/O Error
> --
>
> Key: ARTEMIS-2618
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2618
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Affects Versions: 2.11.0
>Reporter: Rico Neubauer
>Priority: Major
> Fix For: 2.22.0
>
> Attachments: Improve-Handling-of-Shutdown-on-critic.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Would like to request an improvement in the handling of critical I/O errors
> on opening journal files.
> If {{org.apache.activemq.artemis.core.io.nio.NIOSequentialFile}} fails to
> open a journal file, the whole server shuts down with {{@Message(id = 222010,
> value = "Critical IO Error, shutting down the server. file=1, message=0"}}.
> We have seen this in the wild, where a backup-software locked the file for a
> short time while journal was about getting opened, resulting in the shutdown.
> Proposed improvement would be to have a short-running retry for opening the
> journal files and only fail fatally if error persists.
> Will attach a proposal patch. Can also create a PR if you accept.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (ARTEMIS-2965) Allow mirror to stop capture events and delete inner queue
[ https://issues.apache.org/jira/browse/ARTEMIS-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic updated ARTEMIS-2965: - Fix Version/s: 2.22.0 (was: 2.21.0) > Allow mirror to stop capture events and delete inner queue > -- > > Key: ARTEMIS-2965 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2965 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.16.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Critical > Fix For: 2.22.0 > > > When a mirror starts, the current events will not be cleared when > brokerConnection.stop() is called. > > We should support removing the Mirror manager, and deleting the queue upon > brokerConnection.stop(). > (or another method TBD that would determine the semantic to remove the SnF > queue and future generation on mirror). > Related comments: > [https://github.com/apache/activemq-artemis/pull/3316#discussion_r513491335] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3644) Add cert info to CONNECTION_CREATED notification
[ https://issues.apache.org/jira/browse/ARTEMIS-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3644. Fix Version/s: 2.21.0 Resolution: Fixed > Add cert info to CONNECTION_CREATED notification > > > Key: ARTEMIS-3644 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3644 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3724) Update Jetty to 9.4.45
[ https://issues.apache.org/jira/browse/ARTEMIS-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3724. > Update Jetty to 9.4.45 > -- > > Key: ARTEMIS-3724 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3724 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Update Jetty to 9.4.45 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3654) AllClassesTest can create and fail to close a LibaioContext instance
[
https://issues.apache.org/jira/browse/ARTEMIS-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3654.
> AllClassesTest can create and fail to close a LibaioContext instance
>
>
> Key: ARTEMIS-3654
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3654
> Project: ActiveMQ Artemis
> Issue Type: Test
> Components: Tests
>Affects Versions: 2.20.0
>Reporter: Robbie Gemmell
>Assignee: Domenico Francesco Bruscino
>Priority: Minor
> Fix For: 2.21.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> AllClassesTest tries to create objects with random args as part of its check.
> It never closes these.
> A cascading test failure was noticed due to the static TotalMaxIO check done
> before/after ActiveMQTestBase based tests to check for AIO context leaks. As
> AllClassesTest was the only test to run in the JVM before this happened, it
> essentially had to be the cause.
> The behaviour would fit with it generally failing to create the LibaioContext
> instance due to its internal checks, but succeeding this one time, then not
> closing it.
> {noformat}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.apache.activemq.artemis.tests.unit.AllClassesTest
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
> details.
> Warning: Tests run: 1362, Failures: 0, Errors: 0, Skipped: 280, Time
> elapsed: 3.551 s - in org.apache.activemq.artemis.tests.unit.AllClassesTest
> [INFO] Running
> org.apache.activemq.artemis.tests.unit.core.asyncio.MultiThreadAsynchronousFileTest
> [main] 11:27:22,623 ERROR
> [org.apache.activemq.artemis.tests.util.ActiveMQTestBase] LibaioContext
> TotalMaxIO > 0 before beginning test class. Issue presumably arose in a
> preceding class (not possible to be sure of which here). TotalMaxIO = 39416
> [main] 11:27:52,682 ERROR
> [org.apache.activemq.artemis.tests.util.ActiveMQTestBase] LibaioContext
> TotalMaxIO > 0 leak detected after class not-yet-set(), TotalMaxIO=39416().
> Check output to determine if occurred before/during.
> Error: Tests run: 2, Failures: 1, Errors: 1, Skipped: 0, Time elapsed:
> 30.022 s <<< FAILURE! - in
> org.apache.activemq.artemis.tests.unit.core.asyncio.MultiThreadAsynchronousFileTest
> Error:
> org.apache.activemq.artemis.tests.unit.core.asyncio.MultiThreadAsynchronousFileTest
> Time elapsed: 30.022 s <<< ERROR!
> org.junit.TestCouldNotBeSkippedException: Test could not be skipped due to
> other failures
> at
> org.apache.activemq.artemis.tests.unit.core.asyncio.MultiThreadAsynchronousFileTest.hasAIO(MultiThreadAsynchronousFileTest.java:52)
> Error:
> org.apache.activemq.artemis.tests.unit.core.asyncio.MultiThreadAsynchronousFileTest
> Time elapsed: 30.022 s <<< FAILURE!
> java.lang.AssertionError: LibaioContext TotalMaxIO > 0 leak detected after
> class not-yet-set(), TotalMaxIO=39416(). Check output to determine if
> occurred before/during.
> [INFO] Running
> org.apache.activemq.artemis.tests.unit.core.client.impl.LargeMessageBufferTest
> Error: Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.011
> s <<< FAILURE! - in
> org.apache.activemq.artemis.tests.unit.core.client.impl.LargeMessageBufferTest
> Error:
> org.apache.activemq.artemis.tests.unit.core.client.impl.LargeMessageBufferTest
> Time elapsed: 0.011 s <<< FAILURE!
> java.lang.AssertionError: Aborting, LibaioContext TotalMaxIO > 0 issue
> previously detected by test class not-yet-set(), see its output.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3608) OFF_WITH_REDISTRIBUTION - no redistribution for non persistent Multicast messages
[ https://issues.apache.org/jira/browse/ARTEMIS-3608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3608. > OFF_WITH_REDISTRIBUTION - no redistribution for non persistent Multicast > messages > - > > Key: ARTEMIS-3608 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3608 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Anton Roskvist >Priority: Major > Fix For: 2.21.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When running a cluster with OFF_WITH_REDISTRIBUTION load balancing semantics, > non persistent messages sent to a broker without a directly connected > consumer results in dropped messages even if a remote one is present. > This might be expected behavior but I think it's wrong. Setting > OFF_WITH_REDISTRIBUTION I would expect messages to reach a corresponding > consumer regardless of where it is connected in the cluster. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3658) Remove refs to Jetty's deprecated NCSARequestLog
[ https://issues.apache.org/jira/browse/ARTEMIS-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3658. > Remove refs to Jetty's deprecated NCSARequestLog > > > Key: ARTEMIS-3658 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3658 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3662) Remove deprecated config from default broker.xml
[ https://issues.apache.org/jira/browse/ARTEMIS-3662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3662. > Remove deprecated config from default broker.xml > > > Key: ARTEMIS-3662 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3662 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Minor > Fix For: 2.21.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3674) Update to SLF4J 1.7.36
[ https://issues.apache.org/jira/browse/ARTEMIS-3674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3674. > Update to SLF4J 1.7.36 > -- > > Key: ARTEMIS-3674 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3674 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Update to SLF4J 1.7.36 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3655) isolate the ErrorProne dependencies to the profiles that use them
[ https://issues.apache.org/jira/browse/ARTEMIS-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3655. > isolate the ErrorProne dependencies to the profiles that use them > - > > Key: ARTEMIS-3655 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3655 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.20.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The build optionally uses ErrorProne during compilation to catch certain > issues. The ErrorProne dependency was added as a provided dep to various > modules, rather than to the compiler config, as doing so would require > consolidation all annotation processing there. However this means that > ErrorProne and its number of dependencies inc Guava are present on the path > of most modules during the build/tests even when ErrorProne compilation isnt > being used. > This change isolates the dependency to the errorprone profiles, defined only > in the parent pom and inherited by the rest of the modules, thus simplifying > the config, enabling it in places it was not being enabled before, and > ensuring the deps are only present when the compiler is actually being > instructed to use them. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3684) Update Netty to 4.1.74
[ https://issues.apache.org/jira/browse/ARTEMIS-3684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3684. > Update Netty to 4.1.74 > -- > > Key: ARTEMIS-3684 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3684 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3613) Deprecate stompMaxFramePayloadLength which is use for any protocol no just stomp
[ https://issues.apache.org/jira/browse/ARTEMIS-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3613. > Deprecate stompMaxFramePayloadLength which is use for any protocol no just > stomp > > > Key: ARTEMIS-3613 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3613 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Luis Miguel De Bello >Priority: Major > Fix For: 2.21.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > The parameter "stompMaxFramePayloadLength" is used to configured websocket > max frame for any protocal no just for stomp. > > Proposal: > Create a new parameter and use that one instead of the old one, deprecating > the old one to avoid breaking existing usages. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3729) JMS CORE client session commit doesn't work after async sends
[
https://issues.apache.org/jira/browse/ARTEMIS-3729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3729.
> JMS CORE client session commit doesn't work after async sends
> -
>
> Key: ARTEMIS-3729
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3729
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Domenico Francesco Bruscino
>Assignee: Domenico Francesco Bruscino
>Priority: Major
> Fix For: 2.21.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Invoking the commit on a transacted session using the JMS CORE client doesn't
> works after sending async messages. The JMS CORE client doesn't wait for
> server commit response.
> {code:java}
> ActiveMQConnectionFactory activeMQConnectionFactory =
> new ActiveMQConnectionFactory(connectionURL);
> Connection activeMQConnectionFactory.createConnection();
> Session session =
> connection.createSession(Session.SESSION_TRANSACTED);
> MessageProducer producer = session.createProducer(null);
> producer.send(activeMQTopic, createMessage(session, id), instance);
> session.commit();
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3627) Allow properties to configure 'new' broker attributes and load from a file
[ https://issues.apache.org/jira/browse/ARTEMIS-3627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3627. > Allow properties to configure 'new' broker attributes and load from a file > -- > > Key: ARTEMIS-3627 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3627 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Configuration >Affects Versions: 2.20.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 2.21.0 > > Time Spent: 5h 10m > Remaining Estimate: 0h > > Following up on ARTEMIS-851, where simple set attributes can be overridden > via system properties. This enhancement will allow properties to be loaded > from broker.properties and allow additions to lists and maps. > The additions to the collections require some naming convention. Many of the > elements already support a name attribute and this can be used to locate and > or create new entries. > The idea is that a plain broker can be augmented with the presence of a > properties file to add a new acceptor called "tcp" using properties of the > form: > acceptorConfigurations.tcp.params.host=localhost > acceptorConfigurations.tcp.params.port=61616 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3668) Update to Qpid JMS 1.5.0
[ https://issues.apache.org/jira/browse/ARTEMIS-3668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3668. > Update to Qpid JMS 1.5.0 > > > Key: ARTEMIS-3668 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3668 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Update to Qpid JMS 1.5.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3699) add method exposing the bound port of an acceptor
[ https://issues.apache.org/jira/browse/ARTEMIS-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3699. > add method exposing the bound port of an acceptor > - > > Key: ARTEMIS-3699 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3699 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Robin >Assignee: Justin Bertram >Priority: Minor > Fix For: 2.21.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > When creating an instance of EmbeddedActiveMQ the port that the broker binds > to is taken from the acceptor uri supplied to the configuration. Afterwards > there is no easy way to get the port out of the broker instance. In addition, > it would have been nice if one could provide 0 for port to have it start up > on a random available port. Could this be implemented? > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3675) use reload4j in optional openwire tests module
[ https://issues.apache.org/jira/browse/ARTEMIS-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3675. > use reload4j in optional openwire tests module > -- > > Key: ARTEMIS-3675 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3675 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Tests >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.21.0 > > > There is an optionally-enabled test module of additional openwire systests > ported across from ActiveMQ 5 some time ago. Some of the tests themselves use > Log4J 1.2 currently and some of their dependencies inc ActiveMQ bring it in. > The modules deps should be updated so they make use of reload4j instead of > Log4j 1.2. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3710) Deprecate queues config element
[ https://issues.apache.org/jira/browse/ARTEMIS-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3710. > Deprecate queues config element > --- > > Key: ARTEMIS-3710 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3710 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Deprecate queues config element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3677) Mitigate NPE when browsing messages
[ https://issues.apache.org/jira/browse/ARTEMIS-3677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3677. > Mitigate NPE when browsing messages > --- > > Key: ARTEMIS-3677 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3677 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.21.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3685) Support reloading bridges
[ https://issues.apache.org/jira/browse/ARTEMIS-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3685. > Support reloading bridges > - > > Key: ARTEMIS-3685 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3685 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3678) Return proper CONNACK code when MQTT 3.x auth fails
[ https://issues.apache.org/jira/browse/ARTEMIS-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3678. > Return proper CONNACK code when MQTT 3.x auth fails > --- > > Key: ARTEMIS-3678 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3678 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3723) Update Netty to 4.1.75.Final
[ https://issues.apache.org/jira/browse/ARTEMIS-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3723. > Update Netty to 4.1.75.Final > > > Key: ARTEMIS-3723 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3723 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Update Netty to 4.1.75.Final -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3689) Tidy up console build, use consistent plugin versions etc
[ https://issues.apache.org/jira/browse/ARTEMIS-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3689. > Tidy up console build, use consistent plugin versions etc > - > > Key: ARTEMIS-3689 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3689 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Web Console >Affects Versions: 2.20.0 >Reporter: Robbie Gemmell >Priority: Major > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The console build defines various properties that override plugins and > dependency versions already defined [to newer versions] elsewhere in the > build, plus various properties seemingly not used by anything. These can be > tidied up to simplify the build and make it more consistent overall. Spotted > when thinking about doing ARTEMIS-3669. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3631) 2 more header fields can be interpreted as timestamp
[
https://issues.apache.org/jira/browse/ARTEMIS-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3631.
> 2 more header fields can be interpreted as timestamp
>
>
> Key: ARTEMIS-3631
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3631
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Web Console
>Affects Versions: 2.20.0
>Reporter: Erwin Dondorp
>Priority: Minor
> Fix For: 2.21.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When viewing messages using "Browse Queue" (single message view), some header
> fields contain a numeric timestamp. Many of them are recognized and a
> readable timestamp is additionally shown.
> While working with OpenWire messages, there appeared 2 new (for me)
> occurrences: {{\_\_AMQ\_ACTUAL\_EXPIRY}} and {{\_\_HDR\_BROKER\_IN\_TIME}}.
> The matching PR causes these fields to be shown in a readable format as well.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3607) JsonUtil addToObject should be able to add a JsonValue
[ https://issues.apache.org/jira/browse/ARTEMIS-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3607. > JsonUtil addToObject should be able to add a JsonValue > -- > > Key: ARTEMIS-3607 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3607 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.19.0 >Reporter: Emmanuel Hugonnet >Priority: Major > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Adding a JsonObject to a JsonObject using JsonUtil.addToObject will have a > NPE if the value is JsonValue.NULL (NullableJsonString). When adding a > JsonObject (aka a Map of JsonValues) we should use the to String method but > 'just' add the JsonValue -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3650) rework assembly creation to simplify and ease maintenance
[ https://issues.apache.org/jira/browse/ARTEMIS-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3650. > rework assembly creation to simplify and ease maintenance > - > > Key: ARTEMIS-3650 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3650 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.20.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.21.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The current assembly creation process is rather verbose, and can also be > somewhat problematic as result of effectively specifying every jar to > include, often meaning it can both fail to pick up certain changes that occur > in dependencies of the maven modules that then breaks things (e.g > ARTEMIS-3616), or in turn also masking issues in the modules that could > otherwise be visible and noticed in the assembly otherwise (e.g some of the > scope et changes made in the coming diff). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3652) ElasticQueueTest can leave behind task loops creating producers and consumers
[
https://issues.apache.org/jira/browse/ARTEMIS-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3652.
> ElasticQueueTest can leave behind task loops creating producers and consumers
> -
>
> Key: ARTEMIS-3652
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3652
> Project: ActiveMQ Artemis
> Issue Type: Test
> Components: Tests
>Reporter: Robbie Gemmell
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.21.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> ElasticQueueTest can leave behind tasks creating connections in a loop and
> sending+receiving messages on them, and catching exceptions such as those
> caused when trying to stop the task running. The small snippet from a CI log
> below shows it happening. The producer task logs its expected-failure itself
> and can be seen repeating, but it is also visible from the number of
> connection failure logs that there is another loop, for the consumer task
> which does not log its failure itself.
> {noformat}
> expected send failure: javax.jms.JMSException: finishConnect(..) failed:
> Connection refused: localhost/127.0.0.1:61616 PID: 10268637, uri:
> amqp://localhost:61617
> [FailoverProvider: async work thread] 05:39:30,229 ERROR
> [org.apache.qpid.jms.provider.failover.FailoverProvider] Failed to connect
> after: 1 attempt(s)
> [FailoverProvider: async work thread] 05:39:30,229 WARN
> [org.apache.qpid.jms.JmsConnection] Connection
> ID:b454c4b7-c41d-46d7-8e9e-84183ed9b698:1 has failed due to:
> finishConnect(..) failed: Connection refused: localhost/127.0.0.1:61617
> [FailoverProvider: async work thread] 05:39:30,230 ERROR
> [org.apache.qpid.jms.provider.failover.FailoverProvider] Failed to connect
> after: 1 attempt(s)
> [FailoverProvider: async work thread] 05:39:30,230 WARN
> [org.apache.qpid.jms.JmsConnection] Connection
> ID:8604bcff-98b0-4905-80f2-53a0f06516ee:1 has failed due to:
> finishConnect(..) failed: Connection refused: localhost/127.0.0.1:61616
> expected send failure: javax.jms.JMSException: finishConnect(..) failed:
> Connection refused: localhost/127.0.0.1:61616 PID: 10268637, uri:
> amqp://localhost:61617
> [FailoverProvider: async work thread] 05:39:30,231 ERROR
> [org.apache.qpid.jms.provider.failover.FailoverProvider] Failed to connect
> after: 1 attempt(s)
> [FailoverProvider: async work thread] 05:39:30,231 WARN
> [org.apache.qpid.jms.JmsConnection] Connection
> ID:67bb156e-3611-4670-96fd-c0739bfba4e3:1 has failed due to:
> finishConnect(..) failed: Connection refused: localhost/127.0.0.1:61617
> [FailoverProvider: async work thread] 05:39:30,231 ERROR
> [org.apache.qpid.jms.provider.failover.FailoverProvider] Failed to connect
> after: 1 attempt(s)
> [FailoverProvider: async work thread] 05:39:30,231 WARN
> [org.apache.qpid.jms.JmsConnection] Connection
> ID:9ea1925a-3a4a-473f-889b-302d8c867bfe:1 has failed due to:
> finishConnect(..) failed: Connection refused: localhost/127.0.0.1:61617
> [FailoverProvider: async work thread] 05:39:30,237 ERROR
> [org.apache.qpid.jms.provider.failover.FailoverProvider] Failed to connect
> after: 1 attempt(s)
> [FailoverProvider: async work thread] 05:39:30,237 WARN
> [org.apache.qpid.jms.JmsConnection] Connection
> ID:4d529e4f-c2de-4efb-a5f1-a90c80736c98:1 has failed due to:
> finishConnect(..) failed: Connection refused: localhost/127.0.0.1:61616
> {noformat}
> Looking at the test code, this would clearly be caused due to the 'done'
> AtomicBoolean not being tripped and the loop just continuing. This would
> happen as the tests own assertions caused it to fail before it could do so,
> as the summary failures show suggests is what happened:
> {noformat}
> [ERROR] Failures:
> [ERROR] ElasticQueueTest>Assert.fail:89 Thread leaked
> [ERROR]
> ElasticQueueTest.testScale0_1_CombinedProducerConsumerConnectionWithProducerRole:516->Assert.assertTrue:53->Assert.assertTrue:42->Assert.fail:87
> [ERROR]
> ElasticQueueTest.testScale0_1_CombinedRoleConnection:615->Assert.assertTrue:53->Assert.assertTrue:42->Assert.fail:87
> {noformat}
> That failure leaving these tasks behind then probably caused the resulting
> connections/production/consumption to also break a number of tests that
> followed. A small snippet of those continuing directly from above:
> {noformat}
> [ERROR]
> RedirectTest.testLeastConnectionsRedirect:149->testEvenlyRedirect:215->Assert.assertEquals:647->Assert.failNotEquals:835->Assert.fail:89
> Messages of node 2 expected:<1> but was:<0>
> [ERROR]
> TargetKeyTest.testClientIDKey:121->Assert.assertEquals:633->Assert.assertEquals:647->Assert.failNotEquals:835->Assert.fail:89
> expected:<1> but was:<4>
> [ERROR]
>
[jira] [Closed] (ARTEMIS-3624) MVN eclipse:eclipse fails due to missing version for org.apache.kerby/token-provider
[
https://issues.apache.org/jira/browse/ARTEMIS-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3624.
> MVN eclipse:eclipse fails due to missing version for
> org.apache.kerby/token-provider
>
>
> Key: ARTEMIS-3624
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3624
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.20.0
>Reporter: Erwin Dondorp
>Priority: Minor
> Fix For: 2.21.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The topmost pom.xml file lists a dependency on
> {{org.apache.kerby:token-provider}} without specifying a version number. This
> prevents the use of {{mvn eclipse:eclipse}}.
> Simply adding {{2.0.1}} solves the problem.
> -a PR is added.-, but [~robbie] has a better one...
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-2934) ARTEMIS-2226 causes excessive notificaions to be sent for Spring XA clients
[ https://issues.apache.org/jira/browse/ARTEMIS-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-2934. > ARTEMIS-2226 causes excessive notificaions to be sent for Spring XA clients > --- > > Key: ARTEMIS-2934 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2934 > Project: ActiveMQ Artemis > Issue Type: New Feature >Affects Versions: 2.20.0 >Reporter: Anton Roskvist >Priority: Minor > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Hi, > The fix in https://issues.apache.org/jira/browse/ARTEMIS-2226 causes > excessive notifications to be sent for clients running XA transaction through > the Spring framework. > The notifications sent are SESSION_CREATED and SESSION_CLOSED. > I strongly suspect this is because Spring DMLC cannot cache consumers > properly when running XA, causing it to create and remove a new session for > each message processed. > Now I am not arguing that is not bad practice, because it is, but lots of > applications run on top of this logic. I also suspect this might affect more > but not be as pronounced. > > I have been able to prove the aforementioned patch is what causes the issue > by removing: > sendSessionNotification(CoreNotificationType.SESSION_CREATED); > and > sendSessionNotification(CoreNotificationType.SESSION_CLOSED); > from ServerSessionImpl.java (they where added in the patch) > Now I do not fully understand the intent of the original patch but I think it > should be made conditional, that is, send those notifications only for MQTT > session or something similar. > > In the environment I am testing this on the difference is huge as I have a > lot of independent applications all running Spring+XA. About 40% of all > messages getting sent and received are notifications. > > Br, > Anton -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3666) Update to PostgreSQL 42.3.3
[ https://issues.apache.org/jira/browse/ARTEMIS-3666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3666. > Update to PostgreSQL 42.3.3 > --- > > Key: ARTEMIS-3666 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3666 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Update to the latest PostgreSQL release, 42.3.3. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-2582) EmbeddedActiveMQ.stop() should check for null
[
https://issues.apache.org/jira/browse/ARTEMIS-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-2582.
> EmbeddedActiveMQ.stop() should check for null
> -
>
> Key: ARTEMIS-2582
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2582
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.10.1
>Reporter: SL
>Priority: Trivial
> Labels: easy
> Fix For: 2.21.0
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/embedded/EmbeddedActiveMQ.java
> when calling {{EmbeddedActiveMQ.stop()}} method, there is no guarantee that
> the init was called or successful (responsability of the caller)
> the method should check that activeMQServer is not null
> {code:java}
>public EmbeddedActiveMQ stop() throws Exception {
> + if (activeMQServer != null) {
>activeMQServer.stop();
> + }
> return this;
>}
> {code}
> use case : after methods in unit tests.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3715) Support testClientID for artemis-maven-plugin
[ https://issues.apache.org/jira/browse/ARTEMIS-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3715. > Support testClientID for artemis-maven-plugin > - > > Key: ARTEMIS-3715 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3715 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3638) Support MQTT 5
[ https://issues.apache.org/jira/browse/ARTEMIS-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3638. > Support MQTT 5 > -- > > Key: ARTEMIS-3638 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3638 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.21.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3632) expiry timestamps are only shown in relative form in the details table
[
https://issues.apache.org/jira/browse/ARTEMIS-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3632.
> expiry timestamps are only shown in relative form in the details table
> --
>
> Key: ARTEMIS-3632
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3632
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Web Console
>Affects Versions: 2.20.0
>Reporter: Erwin Dondorp
>Priority: Minor
> Fix For: 2.21.0
>
> Attachments: screenshot-1.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When viewing a message using the 'Browse Queue' page, short notations are
> used in the initial table, so that the table does not get too wide.
> When viewing a single message (after using the button 'Show'), there is more
> room to show more information. e.g. timestamp fields get their value shown as
> a date+time. But the "expiration" header field is only shown as an interval
> value when it is within a day from 'now'.
> my proposal is to keep that logic, but to always show the date+time as is
> done outside the range of 1 day.
> e.g.
> current: {{expiration 1641575489820 (in 00:00:22)}}
> new: {{expiration 1641575489820 (in 00:00:22, at 2022-01-07 18:10:59)}}
> or:
> !screenshot-1.png!
> a PR is added
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-2413) Upgrade JGroups
[
https://issues.apache.org/jira/browse/ARTEMIS-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-2413.
> Upgrade JGroups
> ---
>
> Key: ARTEMIS-2413
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2413
> Project: ActiveMQ Artemis
> Issue Type: Dependency upgrade
>Affects Versions: 2.6.4
>Reporter: Endre Jeges
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.21.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I have noticed with the OWASP dependency-check plugin
> (org.owasp:dependency-check-maven:5.0.0) that the currently used
> org.jgroups:jgroups:3.6.13.Final has a [CWE-300: Channel Accessible by
> Non-Endpoint
> ('Man-in-the-Middle')|https://ossindex.sonatype.org/vuln/7c83fdab-9665-4e79-bc81-cc67fbb96417]
> vulnerability. The problem has not been reported in the NVD database,
> therefore there is no CVE record.
> The vulnerability has been
> [addressed|https://github.com/belaban/JGroups/pull/348] in version
> org.jgroups:jgroups:4.0.2.Final (at the moment the latest version is
> org.jgroups:jgroups:4.1.1.Final).
> The org.jgroups:jgroups dependency would require an upgrade to resolve the
> vulnerability.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3145) Failure when shutting down the broker
[
https://issues.apache.org/jira/browse/ARTEMIS-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3145.
> Failure when shutting down the broker
> -
>
> Key: ARTEMIS-3145
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3145
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.16.0
>Reporter: Emmanuel Hugonnet
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.21.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> While shutting down the broker in WildFly we came along the following issue:
> {noformat}
> 2021-02-23 13:17:50,852 INFO [org.apache.activemq.artemis.ra] (ServerService
> Thread Pool -- 39) AMQ151003: resource adaptor stopped
> 2021-02-23 13:17:50,994 ERROR
> [org.apache.activemq.artemis.core.server.impl.FileLockNodeManager] (Thread-1
> (ActiveMQ-scheduled-threads)) java.nio.channels.ClosedChannelException:
> org.apache.activemq.artemis.core.server.NodeManager$NodeManagerException:
> java.nio.channels.ClosedChannelException
> at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.getState(FileLockNodeManager.java:364)
> at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.access$500(FileLockNodeManager.java:36)
> at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager$MonitorLock.run(FileLockNodeManager.java:516)
> at
> org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.runForExecutor(ActiveMQScheduledComponent.java:313)
> at
> org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.bookedRunForScheduler(ActiveMQScheduledComponent.java:328)
> at
> org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.runForScheduler(ActiveMQScheduledComponent.java:339)
> at
> org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.lambda$start$0(ActiveMQScheduledComponent.java:166)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> Caused by: java.nio.channels.ClosedChannelException
> at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:58)
> at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.getState(FileLockNodeManager.java:358)
> ... 13 more
> 2021-02-23 13:17:50,997 WARN
> [org.apache.activemq.artemis.core.server.impl.FileLockNodeManager] (Thread-1
> (ActiveMQ-scheduled-threads)) Lost the lock according to the monitor,
> notifying listeners
> 2021-02-23 13:17:51,493 WARN
> [org.apache.activemq.artemis.core.server.impl.FileLockNodeManager]
> (ServerService Thread Pool -- 39) Failure when accessing a lock file:
> java.nio.channels.ClosedChannelException
> at sun.nio.ch.FileChannelImpl.ensureOpen(FileChannelImpl.java:110)
> at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:1100)
> at java.nio.channels.FileChannel.tryLock(FileChannel.java:1155)
> at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.tryLock(FileLockNodeManager.java:389)
> at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.lock(FileLockNodeManager.java:408)
> at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.writeFileLockStatus(FileLockNodeManager.java:328)
> at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.setPaused(FileLockNodeManager.java:308)
> at
> org.apache.activemq.artemis.core.server.impl.FileLockNodeManager.pauseLiveServer(FileLockNodeManager.java:268)
> at
> org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.close(LiveOnlyActivation.java:104)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1361)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1165)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:1137)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.stop(ActiveMQServerImpl.java:948)
> at
>
[jira] [Closed] (ARTEMIS-3670) Support diverting to multiple addresses
[ https://issues.apache.org/jira/browse/ARTEMIS-3670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3670. > Support diverting to multiple addresses > --- > > Key: ARTEMIS-3670 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3670 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.21.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3687) Bridges with concurrency > 1 can leak
[ https://issues.apache.org/jira/browse/ARTEMIS-3687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3687. > Bridges with concurrency > 1 can leak > - > > Key: ARTEMIS-3687 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3687 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.21.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3695) use specific jetty dependencies instead of jetty-all
[ https://issues.apache.org/jira/browse/ARTEMIS-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3695. > use specific jetty dependencies instead of jetty-all > > > Key: ARTEMIS-3695 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3695 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 2.20.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The build using the 'jetty-all' modules "uber" classified jar as a dependency > in numerous places. This dependency unfortunately also passes on all its > component dependencies of the individual jetty modules it includes, thus > meaning all the artemis modules using it also have the effective duplicate > dependencies (though for the resulting downloadable distribution archive, > only the uber jar is actually packaged in the end tar, due to some specific > filtering used, e.g [1][2]). > The Jetty folks say this artifact was not intended for users and shouldnt be > used, https://www.eclipse.org//lists/jetty-users/msg06029.html. > It has also already been removed in Jetty 10(/11) so this would also impede > upgrading to those newer releases [3]. > The build should just depend on the invididual Jetty bits it needs in each > area. > [1] > https://github.com/apache/activemq-artemis/blob/ee52e3de7c5edb65ee0df463a17387672425b2ba/artemis-distribution/src/main/assembly/dep.xml#L39 > [2] > https://github.com/apache/activemq-artemis/blob/ee52e3de7c5edb65ee0df463a17387672425b2ba/artemis-distribution/src/main/assembly/dep.xml#L50-L52 > [3] [https://github.com/eclipse/jetty.project/issues/5317] > > (A first step might just be to depend on all the individual bits that > jetty-all already does, and which the various modules using jetty-all are > thus in turn already getting. Then afterwards they could be rationalised to > only depend on the bits truly being used by each area). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3591) PagingStoreImpl#checkMemory can run the provided task more than once
[ https://issues.apache.org/jira/browse/ARTEMIS-3591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3591. > PagingStoreImpl#checkMemory can run the provided task more than once > > > Key: ARTEMIS-3591 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3591 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.19.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 2.21.0 > > Time Spent: 40m > Remaining Estimate: 0h > > PagingStoreImpl#checkMemory takes a Runnable argument. It takes steps to > ensure that the given Runnable is an > org.apache.activemq.artemis.utils.runnables.AtomicRunnable, or wraps it as > one, before adding it to the 'onMemoryFreedRunnables' queue for later > execution in some cases. > There is a case where it does this and adds it to the queue > [[1]|https://github.com/apache/activemq-artemis/blob/f8472fd736eff21d21ca2ab0c5a4dd22f0f1d00e/artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/impl/PagingStoreImpl.java#L708], > but then checks the paging state again to guard against a race and can > decide to just run the action immediately > [[2]|https://github.com/apache/activemq-artemis/blob/f8472fd736eff21d21ca2ab0c5a4dd22f0f1d00e/artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/impl/PagingStoreImpl.java#L716]. > However it uses the bare action to run it immediately, not the > potentially-wrapped version it added to the queue by this point. If the > passed Runnable was not already an AtomicRunnable, as it seems many wont be, > then this will mean the original action is likely to be run more than once, > immediately at this point and then again via the AtomicRunnable added to the > queue (the next time the queue is processed). > It should use a reference to the same AtomicRunnable object it adds to the > queue, ensuring the underlying task is either run immediately or later, and > not both. It could additionally try to remove the entry from the queue after > running it. > [1] > [https://github.com/apache/activemq-artemis/blob/f8472fd736eff21d21ca2ab0c5a4dd22f0f1d00e/artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/impl/PagingStoreImpl.java#L708] > [2] > [https://github.com/apache/activemq-artemis/blob/f8472fd736eff21d21ca2ab0c5a4dd22f0f1d00e/artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/impl/PagingStoreImpl.java#L716] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3667) Update to Groovy 4.0.0
[ https://issues.apache.org/jira/browse/ARTEMIS-3667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3667. > Update to Groovy 4.0.0 > -- > > Key: ARTEMIS-3667 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3667 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade > Components: Tests >Reporter: Robbie Gemmell >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The compatibility tests use an old version of Groovy 2. The current release > is now Groovy 4.0.0, we should update to get updates to both it and its > dependencies (and perhaps eventually aid in resolving ARTEMIS-3305) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3712) Refresh doc generation tool-chain
[ https://issues.apache.org/jira/browse/ARTEMIS-3712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3712. > Refresh doc generation tool-chain > - > > Key: ARTEMIS-3712 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3712 > Project: ActiveMQ Artemis > Issue Type: Dependency upgrade >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Minor > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The tools used to generate HTML docs from Markdown are out of date. Notably, > GitBook CLI is now > [deprecated|https://github.com/GitbookIO/gitbook#%EF%B8%8F-deprecation-warning], > but [honkit|https://github.com/honkit/honkit] is a viable replacement. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3734) Correct typo on CLI transfer
[ https://issues.apache.org/jira/browse/ARTEMIS-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3734. Resolution: Fixed > Correct typo on CLI transfer > > > Key: ARTEMIS-3734 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3734 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.20.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.21.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3721) AMQP Mirrored Large Message's body file is not deleted
[ https://issues.apache.org/jira/browse/ARTEMIS-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3721. Resolution: Fixed > AMQP Mirrored Large Message's body file is not deleted > -- > > Key: ARTEMIS-3721 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3721 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.20.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3709) Queue "group-rebalance-pause-dispatch" attribute invalid
[
https://issues.apache.org/jira/browse/ARTEMIS-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3709.
Fix Version/s: 2.21.0
Resolution: Fixed
> Queue "group-rebalance-pause-dispatch" attribute invalid
>
>
> Key: ARTEMIS-3709
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3709
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.20.0
>Reporter: Varsha Kamble
>Priority: Minor
> Labels: documentaion
> Fix For: 2.21.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [Document|https://activemq.apache.org/components/artemis/documentation/latest/message-grouping.html]
> says we can set group-rebalance-pause-dispatch at queue level.
> {code:java}
>
>
>group-rebalance-pause-dispatch="true"/>
>
> {code}
> However broker fails to start as [config
> xsd|https://github.com/apache/activemq-artemis/blob/2.20.0/artemis-server/src/main/resources/schema/artemis-configuration.xsd]
> doesn't define the group-rebalance-pause-dispatch attribute for queueType.
> {code:java}
> "AMQ214019: Invalid configuration: org.xml.sax.SAXParseException;
> cvc-complex-type.3.2.2: Attribute 'group-rebalance-pause-dispatch' is not
> allowed to appear in element 'queue'." "group-rebalance-pause-dispatch" is
> absent in queueType xsd. {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3645) Support broker balancer cache persistence
[ https://issues.apache.org/jira/browse/ARTEMIS-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3645. Fix Version/s: 2.21.0 Resolution: Fixed > Support broker balancer cache persistence > - > > Key: ARTEMIS-3645 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3645 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.21.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The persistence of the broker balancer cache will improve the stickiness of > the connection redirects after a broker restart. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3732) ServerLocator disableFinalizeCheck method has been removed without being deprecated first
[ https://issues.apache.org/jira/browse/ARTEMIS-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3732. Fix Version/s: 2.21.0 Resolution: Fixed > ServerLocator disableFinalizeCheck method has been removed without being > deprecated first > - > > Key: ARTEMIS-3732 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3732 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Emmanuel Hugonnet >Priority: Major > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Removing this method breaks retro compatibility. > We should just provide an empty method instead. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3686) Add example integrating OpenTelemetry
[ https://issues.apache.org/jira/browse/ARTEMIS-3686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3686. Fix Version/s: 2.21.0 Resolution: Fixed > Add example integrating OpenTelemetry > -- > > Key: ARTEMIS-3686 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3686 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Nabwegamo Brendah >Priority: Major > Labels: Outreachy_2021, opentelemetry > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Show case integration of [Opentelemetry|https://opentelemetry.io/] using an > example. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3679) Brokers with JDBC shared-store shutdown after daylight saving fall back
[
https://issues.apache.org/jira/browse/ARTEMIS-3679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3679.
Fix Version/s: 2.21.0
Resolution: Fixed
> Brokers with JDBC shared-store shutdown after daylight saving fall back
> ---
>
> Key: ARTEMIS-3679
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3679
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.20.0
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
> Fix For: 2.21.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> This is what happened on a two brokers JDBC shared-store setup after daylight
> savings change. This also causes the backup shutdown with the same critical
> IO error.
> {code:java}
> 2021-10-31 01:58:44,002 WARN
> [org.apache.activemq.artemis.core.server.impl.jdbc.JdbcLeaseLock] [LIVE]
> d5b17659-c4f6-4847-bfb2-6c5f209a0fb9 query currentTimestamp = 2021-10-31
> 01:58:43.27 on database should happen AFTER 2021-10-31 01:58:44.0 on
> broker 2021-10-31 02:59:00,217 WARN [org.apache.activemq.artemis.core.server]
> AMQ222010: Critical IO Error, shutting down the server. file=NULL,
> message=Lost NodeManager lock: java.io.IOException: lost lock at
> org.apache.activemq.artemis.core.server.impl.SharedStoreLiveActivation.lambda$registerActiveLockListener$0(SharedStoreLiveActivation.java:123)
> [artemis-server-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.core.server.NodeManager.lambda$notifyLostLock$0(NodeManager.java:143)
> [artemis-server-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> java.base/java.lang.Iterable.forEach(Iterable.java:75) [java.base:] at
> org.apache.activemq.artemis.core.server.NodeManager.notifyLostLock(NodeManager.java:141)
> [artemis-server-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.notifyLostLock(JdbcNodeManager.java:154)
> [artemis-server-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.core.server.impl.jdbc.ActiveMQScheduledLeaseLock.run(ActiveMQScheduledLeaseLock.java:114)
> [artemis-server-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.runForExecutor(ActiveMQScheduledComponent.java:313)
> [artemis-commons-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent.lambda$bookedRunForScheduler$2(ActiveMQScheduledComponent.java:320)
> [artemis-commons-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65)
> [artemis-commons-2.16.0.redhat-00012.jar:2.16.0.redhat-00012] at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [java.base:] at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [java.base:] at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> [artemis-commons-2.16.0.redhat-00012.jar:2.16.0.redhat-00012]
> {code}
> The reason seems related to the TIMESTAMP field used on
> HOLDER_EXPIRATION_TIME: given that it doesn't contains any time zone
> information, if it compares against TIMESTAMP WITH TIME ZONE values ie
> CURRENT_TIMESTAMP query results, they won't work as expected.
> In addition, CURRENT_TIMESTAMP values, while converted into the Java world,
> reports UTC time values, while TIMESTAMP ones are adjusted depending by the
> actual time zone (sensitive to day saving time adjustment as well!).
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3660) broker balancer - tidy up configuration; rename to connection router
[
https://issues.apache.org/jira/browse/ARTEMIS-3660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3660.
Resolution: Fixed
> broker balancer - tidy up configuration; rename to connection router
>
>
> Key: ARTEMIS-3660
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3660
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: balancer
>Affects Versions: 2.20.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 2.21.0
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> the use of target in the configuration is a little confusing and extra
> verbose...
> in place of target-key I propose key-type
> in place of target-key-filter I propose key-filter
>
> While released, this feature is not yet used in the wild. I think we can just
> fix this without regard to deprecation at this point.
>
> Going further, I am renaming to better reflect what it does and we can make
> it stable.
> The new name is "Connection Routing" and the "Connection Routers" do
> balancing or partitioning or redirection.
>
> It has been flagged as experimental in the doc[1]:
> This feature is still *EXPERIMENTAL* and not meant to be run in production
> yet. Furthermore, its configuration can change until declared as
> {*}officially stable{*}.
> [1]
> [https://activemq.apache.org/components/artemis/documentation/latest/broker-balancers.html]
>
> new doc will be:
> [https://activemq.apache.org/components/artemis/documentation/latest/connection-routers.html|https://activemq.apache.org/components/artemis/documentation/latest/broker-balancers.html]
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3694) Support remote servers for console smoke tests
[ https://issues.apache.org/jira/browse/ARTEMIS-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3694. Fix Version/s: 2.21.0 Resolution: Fixed > Support remote servers for console smoke tests > -- > > Key: ARTEMIS-3694 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3694 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3618) Faster Artemis CORE client MessageListener::onMessage without SecurityManager
[
https://issues.apache.org/jira/browse/ARTEMIS-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3618.
Fix Version/s: 2.21.0
Resolution: Fixed
> Faster Artemis CORE client MessageListener::onMessage without SecurityManager
> -
>
> Key: ARTEMIS-3618
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3618
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Major
> Fix For: 2.21.0
>
> Attachments: noSecurityManager.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently {{{}ClientConsumerImpl{}}}, responsible of calling JMS
> {{{}MessageListener::onMessage{}}}, is installing/restoring the listener
> thread's context ClassLoader by using a secured action regardless any
> security manager is installed.
> This secured action (using {{{}AccessController::doPrivileged{}}}) is very
> heavyweight and can often be as costy (or more) then the user/application
> code handling the received message (see
> [https://bugs.openjdk.java.net/browse/JDK-8062162] for more info).
> The {{SecurityManager}} will be removed in the future (see
> [https://openjdk.java.net/jeps/411]) but until that moment would be nice to
> reduce such cost at least if no {{SecurityManager}} is installed.
> This is a flamegraph showing the listener stack trace:
> !noSecurityManager.png|width=920,height=398!
> As the image shows, in violet, here's the cost of
> {{AccessController::doPrivileged}} if no {{SecurityManager}} is installed ie
> 14 samples
> - handling the message costs 3 samples
> - acknowledge it costs 19 samples
> TLDR {{AccessController::doPrivileged}} cost ~5 times handling the message
> and nearly the same as acking back it
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3646) OpenWire clients leave incorrect queue metrics when messages are sent to DLQ
[
https://issues.apache.org/jira/browse/ARTEMIS-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3646.
Fix Version/s: 2.21.0
Resolution: Fixed
> OpenWire clients leave incorrect queue metrics when messages are sent to DLQ
>
>
> Key: ARTEMIS-3646
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3646
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Anton Roskvist
>Priority: Major
> Fix For: 2.21.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {color:#1d1c1d}Messages getting sent to DLQ from an OpenWire client leaves
> incorrect queue metrics behind. {color}{color:#1d1c1d}"DeliveringSize"
> "DurableDeliveringSize"
> "DurablePersistentSize"
> "PersistentSize"
> All metrics above end up with negative values, even if the consumers are
> later disconnected or if the messages are retried and successfully consumed.
> I am able to reproduce this easily with an Artemis broker running
> "out-of-the-box"-config and using the following clients:
> [https://github.com/erik-wramner/JmsTools] (AmqJmsConsumer.jar and
> AmqJmsProducer.jar)
> Example:
> {color}
> {code:java}
> # java -jar shaded-jars/AmqJmsProducer.jar -url "tcp://localhost:61616" -user
> USER -pw PASSWORD -queue TEST -count 100{code}
> {code:java}
> # java -jar shaded-jars/AmqJmsConsumer.jar -url "tcp://localhost:61616" -user
> USER -pw PASSWORD -queue TEST -count 1 -rollback 100 -t 10{code}
> {color:#1d1c1d}
> Using Artemis clients from the same tools results in no such issue. I am
> seeing the issue with other OpenWire clients also
> Br,{color}
> {color:#1d1c1d}Anton{color}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3641) Move to the latest checkstyle
[ https://issues.apache.org/jira/browse/ARTEMIS-3641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3641. Fix Version/s: 2.21.0 Resolution: Fixed > Move to the latest checkstyle > - > > Key: ARTEMIS-3641 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3641 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3647) rolledbackMessageRefs can grow until OOM with OpenWire clients
[
https://issues.apache.org/jira/browse/ARTEMIS-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3647.
Fix Version/s: 2.21.0
Resolution: Fixed
> rolledbackMessageRefs can grow until OOM with OpenWire clients
> --
>
> Key: ARTEMIS-3647
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3647
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Anton Roskvist
>Priority: Major
> Fix For: 2.21.0
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> {color:#1d1c1d}In my use case I have quite a few long lived OpenWire
> consumers. I noticed that over time the heap usage increases. Looking through
> a heap dump, I found that memory is held in "rolledbackMessageRefs". In one
> case holding as much as 1.6GB of data with 0 messages on queue.
> Disconnecting the consumer and then reconnecting released the memory.
> Clients are running Spring with transactions. The clients affected by this
> have some small issue receiving messages such that some of them are retried a
> couple of times before getting processed properly.
> I suspect that "rolledbackMessageRefs"{color} are not getting cleared with
> the message ref once it's finally processed for some reason.
> {-}{color:#1d1c1d}I have not found a way to reproduce this yet and it happens
> over several days.
> {color}{-}{color:#1d1c1d}UPDATE: I can easily reproduce this by setting up a
> standalone Artemis broker with "out-of-the-box"-configuration and using these
> tools:{color} -- [https://github.com/erik-wramner/JmsTools] (AmqJmsConsumer
> and optionally AmqJmsProducer)
> 1. Start the broker
> 2. Send 100k messages to "queue://TEST"
> {code:java}
> # java -jar JmsTools/shaded-jars/AmqJmsProducer.jar -url
> "tcp://localhost:61616" -user USER -pw PASSWORD -queue TEST -count
> 10{code}
> 3. Receive one more message than produced and do a rollback on 30% of them
> (unrealistic, but means this can be done in minutes instead of days. Receive
> one more to ensure consumer stays live)
> {code:java}
> # java -jar JmsTools/shaded-jars/AmqJmsConsumer.jar -url
> "tcp://localhost:61616?jms.prefetchPolicy.all=100=true"
> -user USER -pw PASSWORD -queue TEST -count 11 -rollback 30{code}
> 4. Wait until no more messages are left on "queue://TEST" (a few might be on
> DLQ but that's okay)
> 5. Get a heap dump with the consumer still connected
> {code:java}
> # jmap -dump:format=b,file=dump.hprof Artemis_PID{code}
> 6. Running "Leak suspects" with MAT will show a (relatively) large amount of
> memory held by {color:#1d1c1d}"rolledbackMessageRefs"{color} for the consumer
> connected to queue://TEST
> The consumer is run with "jms.nonBlockingRedelivery=true" to speed things up,
> though it should not be strictly needed.
> As an added bonus this also shows that the prefetch limit
> "jms.prefetchPolicy.all=100" is not respected while messages are in the
> redelivery process which can easily be seen in the consoles
> "Attributes"-section for the queue. This is also true for the default
> prefetch value of 1000.
> Br,
> Anton
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3711) Support AMQ_SCHEDULED_DELAY for OpenWire clients
[
https://issues.apache.org/jira/browse/ARTEMIS-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3711.
Fix Version/s: 2.21.0
Resolution: Fixed
> Support AMQ_SCHEDULED_DELAY for OpenWire clients
>
>
> Key: ARTEMIS-3711
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3711
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.21.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Support {{AMQ_SCHEDULED_DELAY}} as described in the [ActiveMQ "Classic"
> documentation|https://activemq.apache.org/delay-and-schedule-message-delivery].
> This will help users migrating to Artemis.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3690) Enhancement of ActiveMQRAManagedConnectionFactory by compressLargeMessage and initialConnectAttempts
[ https://issues.apache.org/jira/browse/ARTEMIS-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3690. Fix Version/s: 2.21.0 Resolution: Fixed > Enhancement of ActiveMQRAManagedConnectionFactory by compressLargeMessage and > initialConnectAttempts > > > Key: ARTEMIS-3690 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3690 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.19.1 >Reporter: Patrick Kerner >Priority: Minor > Fix For: 2.21.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > The option compressLargeMessage and initialConnectAttempts is not available > in ActiveMQRAManagedConnectionFactory but in the Core ConnectionFactory. > > W J2CA8501E: Property initialConnectAttempts of configuration element > jms/wmqCF cannot be set because it is not found on the class > org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3716) Move end-to-end tests from smoke-tests to e2e-tests module
[ https://issues.apache.org/jira/browse/ARTEMIS-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3716. Resolution: Fixed > Move end-to-end tests from smoke-tests to e2e-tests module > -- > > Key: ARTEMIS-3716 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3716 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Tests >Reporter: Tiago Bueno >Priority: Minor > Labels: test > Fix For: 2.21.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Move all tests which are related to end-to-end testing from smoke-tests > module to a new module named e2e-tests. > These e2e tests are those which are dependent of ContainerService class. > ContainerService class uses artemis inside a container by using the > testcontainers library and for that reason these tests are usually a quite > slow and tecnically they are not a smoke test. > The new e2e-tests module is part of tests module but it is not enabled by > default and to get executed it requires the e2e-tests profile specification > on maven command. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3691) Build the CLI connector from a broker acceptor
[ https://issues.apache.org/jira/browse/ARTEMIS-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3691. Fix Version/s: 2.21.0 Resolution: Fixed > Build the CLI connector from a broker acceptor > -- > > Key: ARTEMIS-3691 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3691 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3573) Support PropertiesLoginModule custom password codecs
[ https://issues.apache.org/jira/browse/ARTEMIS-3573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3573. Fix Version/s: 2.21.0 Resolution: Fixed > Support PropertiesLoginModule custom password codecs > > > Key: ARTEMIS-3573 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3573 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.21.0 > > Time Spent: 6h > Remaining Estimate: 0h > > The `PropertiesLoginModule` login module supports only the > `DefaultSensitiveStringCodec` codec to verify the user passwords. > Add a property to set a custom password codec, i.e. > org.apache.activemq.jaas.properties.password.codec="org.apache.activemq.artemis.tests.integration.security.MD5SensitiveDataCodec" -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3653) BrokerDiagram improvements, a.o. highlight the (real) current broker
[ https://issues.apache.org/jira/browse/ARTEMIS-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3653. Resolution: Fixed > BrokerDiagram improvements, a.o. highlight the (real) current broker > > > Key: ARTEMIS-3653 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3653 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Web Console >Affects Versions: 2.20.0 >Reporter: Erwin Dondorp >Priority: Minor > Fix For: 2.21.0 > > Attachments: screenshot-1.png, screenshot-2.png > > Time Spent: 50m > Remaining Estimate: 0h > > When viewing the broker diagram with up to one or two master brokers (and > optionally a slave broker for each) then it is unclear which broker is the > current broker. > When there are 3 or more master brokers, the connections between the brokers > provide a clue (as the one with multiple connections is from the current > pair). but still it is unclear whether the master broker or the slave broker > of the current pair is the current broker. > The PR for this change introduces highlighting of the current node and the > display of spare slave brokers. Additionally, the previous implementation is > fixed where needed. > Details: > * Remove comments about icons used for address/queue nodes as it does not > even use an icon (I guess it might have done so in the past); > * Do not show ":61616" in the broker name, as that is the default; > * Do not show quotes around addresses and queues; > * The node-type "ThisBroker" is split into "ThisMasterBroker" and > "ThisSlaveBroker". "ThisMasterBroker" has the same style as "MasterBroker", > but just with a black border. "ThisSlaveBroker" has the same style as > "SlaveBroker", but just with a black border. These styles are applied as > appropriate; > * Only show the details when the current broker is selected. Previously the > details were shown when the corresponding master broker was selected. That > was correct when the current node was a master, but not when the current > broker was a slave; > * When the current broker cannot be found in the reported topology, use the > current broker-name instead of the text "broker". The brokers that are found > in the topology are labelled with their hostname, so it is slightly > different. The hostname does not seem to be available in the information that > is retrieved for this diagram. But it's too much work to get the actual > hostname as far as I can tell. > * When the connectors list shows brokers that are not part of the cluster, > also show these brokers. the broker is drawn as a white circle with red > border. Such brokers may be spare slave brokers (when there are more slave > brokers than master brokers) or brokers that are not connected to yet. > * Do not show the checkbox controls for which the diagram will not change > The end-result still looks familiar in most cases, but note the slightly > different border of the middle master broker: > !screenshot-1.png! > In case spare slave brokers are used or when other brokers are just not > connected: > !screenshot-2.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3701) Do not block libaio before moving to next file.
[
https://issues.apache.org/jira/browse/ARTEMIS-3701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3701.
Resolution: Fixed
> Do not block libaio before moving to next file.
> ---
>
> Key: ARTEMIS-3701
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3701
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.20.0
>Reporter: Clebert Suconic
>Assignee: Clebert Suconic
>Priority: Major
> Fix For: 2.21.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> this is to avoid the following error message:
> AIOSequentialFileFactory.threadDump("File " + getFileName() + " still has
> pending IO before closing it");
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3696) Avoid null property values on STOMP messages
[ https://issues.apache.org/jira/browse/ARTEMIS-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3696. Fix Version/s: 2.21.0 Resolution: Fixed > Avoid null property values on STOMP messages > > > Key: ARTEMIS-3696 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3696 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3719) Dead-letter and expiry address not applied when using temp-queue-namespace
[ https://issues.apache.org/jira/browse/ARTEMIS-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3719. Fix Version/s: 2.21.0 Resolution: Fixed > Dead-letter and expiry address not applied when using temp-queue-namespace > -- > > Key: ARTEMIS-3719 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3719 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.21.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3673) Set default hawtio role
[ https://issues.apache.org/jira/browse/ARTEMIS-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3673. Fix Version/s: 2.21.0 Resolution: Fixed > Set default hawtio role > --- > > Key: ARTEMIS-3673 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3673 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3621) viewing message without timestamp shows a 1970 datetime
[
https://issues.apache.org/jira/browse/ARTEMIS-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3621.
Resolution: Fixed
> viewing message without timestamp shows a 1970 datetime
> ---
>
> Key: ARTEMIS-3621
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3621
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Web Console
>Affects Versions: 2.20.0
>Reporter: Erwin Dondorp
>Priority: Minor
> Fix For: 2.21.0
>
> Attachments: image-2021-12-29-15-09-06-739.png, screenshot-1.png,
> screenshot-2.png, screenshot-4.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When showing a message without timestamp, it is shown as "1970-01-01
> 01:00:00" (exact value is time zone dependent).
> This is because the internal value is 0.
> e.g.:
> !screenshot-2.png!
> and:
> !screenshot-1.png!
> An alternative value should be shown instead. I chose "{{{}none{}}}".
> Additionally, a nearby comment is fixed.
> A simple PR is available.
> The new output is:
> !image-2021-12-29-15-09-06-739.png!
> and:
> !screenshot-4.png!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3657) Refactor address docs
[ https://issues.apache.org/jira/browse/ARTEMIS-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3657. Fix Version/s: 2.21.0 Resolution: Fixed > Refactor address docs > - > > Key: ARTEMIS-3657 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3657 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.21.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3682) No way of knowing if a bridge was successfully deployed or not
[ https://issues.apache.org/jira/browse/ARTEMIS-3682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3682. Fix Version/s: 2.21.0 Resolution: Fixed > No way of knowing if a bridge was successfully deployed or not > -- > > Key: ARTEMIS-3682 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3682 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: Emmanuel Hugonnet >Priority: Minor > Fix For: 2.21.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently the deploybridge() method doesn't return any status to tell if the > deployment was successful or not. It should return a boolean so that we can > do something about it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3698) Avoid byte[] property values when converting from OpenWire
[
https://issues.apache.org/jira/browse/ARTEMIS-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3698.
Fix Version/s: 2.21.0
Resolution: Fixed
> Avoid byte[] property values when converting from OpenWire
> --
>
> Key: ARTEMIS-3698
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3698
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.21.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Here's some example code using the Qpid JMS client:
> {code:java}
> session.createConsumer(queue).setMessageListener(message -> {
> try {
> Map headers = new TreeMap<>();
> Enumeration en = (Enumeration)
> message.getPropertyNames();
> while (en.hasMoreElements()) {
> String name = en.nextElement();
> headers.put(name, message.getStringProperty(name));
> }
> System.out.println(headers);
> } catch (Exception e) {
> e.printStackTrace();
> }
> });
> {code}
> If an OpenWire JMS client sends messages to this queue the following
> exception is thrown:
> {code:java}
> javax.jms.MessageFormatException: Property __HDR_MESSAGE_ID was a
> org.apache.qpid.proton.amqp.Binary and cannot be read as a java.lang.String
> at
> org.apache.qpid.jms.message.JmsMessagePropertySupport.convertPropertyTo(JmsMessagePropertySupport.java:47)
> at
> org.apache.qpid.jms.message.JmsMessage.getStringProperty(JmsMessage.java:393)
> at com.mycompany.camel.AMQClient2.lambda$main$0(AMQClient2.java:34)
> at
> org.apache.qpid.jms.JmsMessageConsumer.deliverNextPending(JmsMessageConsumer.java:749)
> at
> org.apache.qpid.jms.JmsMessageConsumer.access$100(JmsMessageConsumer.java:58)
> at
> org.apache.qpid.jms.JmsMessageConsumer$MessageDeliverTask.run(JmsMessageConsumer.java:808)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.jms.util.QpidJMSThreadFactory$1.run(QpidJMSThreadFactory.java:86)
> at java.lang.Thread.run(Thread.java:748){code}
> Despite the fact section 3.5.4 of the JMS 2 spec notes that all supported
> properties should be convertible to {{java.lang.String}} it's important to
> note that the broker supports much more than just JMS. Even the supported
> wire protocols used by JMS clients support much more than just JMS.
> Therefore, there are going to be instances where certain conversions are not
> possible. The JMS API has support for dealing with these instances (e.g. via
> the {{MessageFormatException}}) and clients should be written to deal with
> them. In fact, it is _critical_ for a consumer to validate a message's data
> and protect itself from unexpected circumstances.
> That said, it would be nice to avoid {{byte[]}} property values to improve
> the user experience. Therefore, I will update the broker to eliminate
> {{byte[]}} values when converting between properties known to be used by the
> OpenWire JMS client and the broker's core message format _where possible_.
> This will mitigate the instances of {{MessageFormatException}} observed in
> the code in the description, but it will not eliminate all potential
> instances of {{MessageFormatException}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3697) Paging improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-3697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3697. Fix Version/s: 2.21.0 Resolution: Fixed > Paging improvements > --- > > Key: ARTEMIS-3697 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3697 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.21.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > This is > - Remove page Readers and just keep references in the memory > - use reference counting for active readers on pages.. just keep the page > while a reader still using it. > - Remove Weak and SoftReferences > - Minimize use on Page Transactions (cleanup them and update page files) > - minimize use on Page counters -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3676) "No route to host" exceptions from Netty with NIO transport
[
https://issues.apache.org/jira/browse/ARTEMIS-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3676.
Fix Version/s: 2.21.0
Resolution: Fixed
> "No route to host" exceptions from Netty with NIO transport
> ---
>
> Key: ARTEMIS-3676
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3676
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: API
>Affects Versions: 2.19.1, 2.20.0
>Reporter: Apache Dev
>Priority: Minor
> Fix For: 2.21.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following exception is logged when client transport connector is
> configured with broker hosts currently not available. For example, when
> configured host is down, which is a situation possible in a container
> environment:
> {code}
> [2/8/22 15:31:31:678 CET] 0101 org.apache.activemq.artemis.core.client
> E AMQ214016: Failed to create netty connection
> io.netty.channel.AbstractChannel$AnnotatedNoRouteToHostException: No route to
> host: activemq2/172.10.0.52:61617
> Caused by: java.net.NoRouteToHostException: No route to host
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:716)
> at
> io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect(NioSocketChannel.java:330)
> at
> io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.finishConnect(AbstractNioChannel.java:334)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:710)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
> {code}
>
> Artemis 2.16 did not log such exceptions (they were handled as transient
> connection errors).
> Artemis intercepts Netty exception in
> {{org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector#createConnection(java.util.function.Consumer,
> java.lang.String, int)}}
> and logs it as an error because it is not a ConnectException:
> {code}
> if (t != null && !(t instanceof ConnectException)) {
>
> ActiveMQClientLogger.LOGGER.errorCreatingNettyConnection(future.cause());
> }
> {code}
> I think it should be handled like a transient connection error, similar to
> what happens when host machine is up and running but broker is not active.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3522) Implement performance tools to evaluate throughput and Response Under Load performance of Artemis
[ https://issues.apache.org/jira/browse/ARTEMIS-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3522. Fix Version/s: 2.21.0 Resolution: Fixed > Implement performance tools to evaluate throughput and Response Under Load > performance of Artemis > - > > Key: ARTEMIS-3522 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3522 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker, JMS >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Fix For: 2.21.0 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > There are many performance benchmarks around eg [SoftwareMill > MqPerf|https://softwaremill.com/mqperf/] that could be used to test > performance of Artemis in specific scenario, but none is both simple and easy > to be composed with ad-hoc env setup scripts to perform a wide range of > different performance tests against the broker. > This JIRA aim to provide CLI commands that could be used as building blocks > to perform: > * all-out throughput tests > * responsiveness under load tests (with no [coordinated > omission|http://highscalability.com/blog/2015/10/5/your-load-generator-is-probably-lying-to-you-take-the-red-pi.html]) > ie fixed throughput (per producer) load > * scalability tests > The effort of this JIRA should produce CLI commands similar to [Apache Pulsar > Perf|https://pulsar.apache.org/docs/en/performance-pulsar-perf/] that could > be composed to create complete performance benchmark pipelines (eg using > [qDup|https://github.com/Hyperfoil/qDup] and > [Horreum|https://github.com/Hyperfoil/Horreum] on a CI/CD) or used as-it-is > by users to quickly check performance of the broker. > Requirements: > * support AMQP and Core protocol > * cross JVMs with microseconds time measurement granularity > * support parsable output format > * suitable to perform scale tests > The last requirement can be achieved both by using MessageListeners and async > producers available on [JMS > 2|https://javaee.github.io/jms-spec/pages/JMS20FinalRelease] although both > [qpid JMS|https://github.com/apache/qpid-jms] and Artemis Core protocols > blocks the producer caller thread ie the former on > [jmsConnection::send|https://github.com/apache/qpid-jms/blob/1622de679c3c6763db54e9ac506ef2412fbc4481/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsConnection.java#L773], > awaiting Netty threads to unblock it on > [AmqpFixedProducer::doSend|https://github.com/apache/qpid-jms/blob/1622de679c3c6763db54e9ac506ef2412fbc4481/qpid-jms-client/src/main/java/org/apache/qpid/jms/provider/amqp/AmqpFixedProducer.java#L169], > while the latter on > [ClientProducerImpl::sendRegularMessage|https://github.com/apache/activemq-artemis/blob/e364961c8f035613f3ce4e3bdb3430a17efb0ffd/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ClientProducerImpl.java#L284-L294]. > This seems odd because [JMS 2's > CompletionListener|https://docs.oracle.com/javaee/7/api/javax/jms/CompletionListener.html] > should save any previous send operation to ever block and the user should > take care (despite being tedious and error-prone) to track the amount of > in-flight messages and limit it accordly (ie [Reactive Messaging's > Emitter|https://smallrye.io/smallrye-reactive-messaging/smallrye-reactive-messaging/2/emitter/emitter.html#emitter-overflow] > abstract it with its overflow policies to save blocking the caller thread). > If JMS 2 both impl cannot be turned into non-blocking then there're just 2 > options: > # using the blocking variant: it means that scalability tests requires using > machines with high core numbers > # using [Reactive > Messaging|https://github.com/eclipse/microprofile-reactive-messaging], but > losing the ability to use local transactions (and maybe other JMS features) > With the first option the number of producers threads can easily be much more > then the available cores, causing the load generator to benchmark OS (or the > runtime) ability to context switch threads instead of the broker. That's why > a non-blocking approach should be preferred. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3720) Max number of messages as a deciding factor for Paging
[ https://issues.apache.org/jira/browse/ARTEMIS-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3720. Resolution: Fixed > Max number of messages as a deciding factor for Paging > -- > > Key: ARTEMIS-3720 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3720 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.21.0 > > Time Spent: 9h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3708) Collapse key transformer into policy
[ https://issues.apache.org/jira/browse/ARTEMIS-3708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3708. Fix Version/s: 2.21.0 Resolution: Fixed > Collapse key transformer into policy > > > Key: ARTEMIS-3708 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3708 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.21.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3186) enable option "Create queue" more often
[ https://issues.apache.org/jira/browse/ARTEMIS-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3186. Resolution: Fixed > enable option "Create queue" more often > --- > > Key: ARTEMIS-3186 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3186 > Project: ActiveMQ Artemis > Issue Type: Wish > Components: Web Console >Affects Versions: 2.17.0 >Reporter: Erwin Dondorp >Priority: Minor > Fix For: 2.21.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The option "Create queue" is only enabled in the gui when an address is > selected. > It makes sense to enable it also when: > * the item "queues" under the address is selected; or > * the item "multicast" or "anycast" under the address is selected (but not > when "divert" is selected). In that case, the "Routing type" can even be > prefilled with the already selected routing type. > A PR is added -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3714) Change Docker group and user IDs to 1001
[ https://issues.apache.org/jira/browse/ARTEMIS-3714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3714. Fix Version/s: 2.21.0 Resolution: Fixed > Change Docker group and user IDs to 1001 > > > Key: ARTEMIS-3714 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3714 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.21.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3702) Authorization failures don't adhere to MQTT spec
[ https://issues.apache.org/jira/browse/ARTEMIS-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3702. Fix Version/s: 2.21.0 Resolution: Fixed > Authorization failures don't adhere to MQTT spec > > > Key: ARTEMIS-3702 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3702 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.21.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3671) Fix readability of queue stat output
[
https://issues.apache.org/jira/browse/ARTEMIS-3671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clebert Suconic closed ARTEMIS-3671.
Fix Version/s: 2.21.0
Resolution: Fixed
> Fix readability of queue stat output
>
>
> Key: ARTEMIS-3671
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3671
> Project: ActiveMQ Artemis
> Issue Type: Improvement
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.21.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Say you create a few queues using the following commands:
> {noformat}
> $ ./artemis queue create --name 012345678901234567890123456789a --address
> 012345678901234567890123456789a --anycast --preserve-on-no-consumers
> --durable --auto-create-address
> $ ./artemis queue create --name 012345678901234567890123456789b --address
> 012345678901234567890123456789b --anycast --preserve-on-no-consumers
> --durable --auto-create-address
> $ ./artemis queue create --name 012345678901234567890123456789c --address
> 012345678901234567890123456789c --anycast --preserve-on-no-consumers
> --durable --auto-create-address{noformat}
> Then run this command:
> {noformat}
> $ ./artemis queue stat{noformat}
> This is what the output would be like:
> {noformat}
> |NAME |ADDRESS |CONSUMER_COUNT
> |MESSAGE_COUNT |MESSAGES_ADDED |DELIVERING_COUNT |MESSAGES_ACKED
> |SCHEDULED_COUNT |ROUTING_TYPE |
> |012345678901234567890123456789a|012345678901234567890123456789a|0
> |0 |0 |0|0 |0
> |ANYCAST |
> |012345678901234567890123456789b|012345678901234567890123456789b|0
> |0 |0 |0|0 |0
> |ANYCAST |
> |012345678901234567890123456789c|012345678901234567890123456789c|0
> |0 |0 |0|0 |0
> |ANYCAST |
> |DLQ |DLQ |0 |0
> |0 |0|0 |0
> |ANYCAST |
> |ExpiryQueue |ExpiryQueue |0 |0
> |0 |0|0 |0
> |ANYCAST |
> |activemq.management.d88b1e8e-b33b-4419-bda6-611a54a6c111|activemq.management.d88b1e8e-b33b-4419-bda6-611a54a6c111|1
> |0 |0 |0|0
> |0 |MULTICAST|{noformat}
> The output is a mess. It's hard to line up the columns to know what's what.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (ARTEMIS-3664) Critical Analyzer should not kick in during Starting phase of the broker
[ https://issues.apache.org/jira/browse/ARTEMIS-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clebert Suconic closed ARTEMIS-3664. Resolution: Fixed > Critical Analyzer should not kick in during Starting phase of the broker > > > Key: ARTEMIS-3664 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3664 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.19.1, 2.20.0 >Reporter: Clebert Suconic >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Say the journal is too big to be loaded in less than 2 minutes or the CPU is > not powerful enough... anything... > the system should not give up loading the journal.. and it should not HALT > the startup of the broker. Up to that point it should instead just log.warn. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3734) Correct typo on CLI transfer
[ https://issues.apache.org/jira/browse/ARTEMIS-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510713#comment-17510713 ] ASF subversion and git services commented on ARTEMIS-3734: -- Commit 4bca3d1375ee6dfc8e952ba1ae89aa3cede726ad in activemq-artemis's branch refs/heads/main from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=4bca3d1 ] ARTEMIS-3734 Correcting typo on documentation for CLI Transfer > Correct typo on CLI transfer > > > Key: ARTEMIS-3734 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3734 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.20.0 >Reporter: Clebert Suconic >Assignee: Clebert Suconic >Priority: Major > Fix For: 2.21.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (ARTEMIS-3734) Correct typo on CLI transfer
Clebert Suconic created ARTEMIS-3734: Summary: Correct typo on CLI transfer Key: ARTEMIS-3734 URL: https://issues.apache.org/jira/browse/ARTEMIS-3734 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.20.0 Reporter: Clebert Suconic Assignee: Clebert Suconic Fix For: 2.21.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work started] (ARTEMIS-3710) Deprecate queues config element
[ https://issues.apache.org/jira/browse/ARTEMIS-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on ARTEMIS-3710 started by Domenico Francesco Bruscino. > Deprecate queues config element > --- > > Key: ARTEMIS-3710 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3710 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Deprecate queues config element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (ARTEMIS-3710) Deprecate queues config element
[ https://issues.apache.org/jira/browse/ARTEMIS-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Francesco Bruscino resolved ARTEMIS-3710. -- Resolution: Fixed > Deprecate queues config element > --- > > Key: ARTEMIS-3710 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3710 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Deprecate queues config element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3710) Deprecate queues config element
[ https://issues.apache.org/jira/browse/ARTEMIS-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Francesco Bruscino updated ARTEMIS-3710: - Fix Version/s: 2.21.0 > Deprecate queues config element > --- > > Key: ARTEMIS-3710 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3710 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Fix For: 2.21.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Deprecate queues config element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (ARTEMIS-3710) Deprecate queues config element
[ https://issues.apache.org/jira/browse/ARTEMIS-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510493#comment-17510493 ] ASF subversion and git services commented on ARTEMIS-3710: -- Commit 41463c83971172955a270572a37ef375c596b0de in activemq-artemis's branch refs/heads/main from Domenico Francesco Bruscino [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=41463c8 ] ARTEMIS-3710 Deprecate queues config element > Deprecate queues config element > --- > > Key: ARTEMIS-3710 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3710 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > > Deprecate queues config element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (ARTEMIS-3710) Deprecate queues config element
[ https://issues.apache.org/jira/browse/ARTEMIS-3710?focusedWorklogId=745827=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-745827 ] ASF GitHub Bot logged work on ARTEMIS-3710: --- Author: ASF GitHub Bot Created on: 22/Mar/22 13:37 Start Date: 22/Mar/22 13:37 Worklog Time Spent: 10m Work Description: clebertsuconic merged pull request #3992: URL: https://github.com/apache/activemq-artemis/pull/3992 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 745827) Remaining Estimate: 0h Time Spent: 10m > Deprecate queues config element > --- > > Key: ARTEMIS-3710 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3710 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Deprecate queues config element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (ARTEMIS-3733) Destination cache size too small for OpenWire clients
Anton Roskvist created ARTEMIS-3733: --- Summary: Destination cache size too small for OpenWire clients Key: ARTEMIS-3733 URL: https://issues.apache.org/jira/browse/ARTEMIS-3733 Project: ActiveMQ Artemis Issue Type: Improvement Reporter: Anton Roskvist For brokers dealing with OpenWire clients and a large number of destination the default destination cache is fixed at 16 destinations leading to a lot of overhead for looking up destinations when there are lots of them. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (ARTEMIS-3710) Deprecate queues config element
[ https://issues.apache.org/jira/browse/ARTEMIS-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Domenico Francesco Bruscino updated ARTEMIS-3710: - Description: Deprecate queues config element. (was: Deprecate queues config element and add missing attributes (group-rebalance-pause-dispatch) to queueType) > Deprecate queues config element > --- > > Key: ARTEMIS-3710 > URL: https://issues.apache.org/jira/browse/ARTEMIS-3710 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Domenico Francesco Bruscino >Assignee: Domenico Francesco Bruscino >Priority: Major > > Deprecate queues config element. -- This message was sent by Atlassian Jira (v8.20.1#820001)
