[GitHub] activemq-artemis issue #1771: ARTEMIS-1600 Support masked passwords in boots...

[gaohoward]

Github user gaohoward commented on the issue:

https://github.com/apache/activemq-artemis/pull/1771
  
@jbertram ok I think we can support ENC() as well as "mask-password".


---

[GitHub] activemq-artemis issue #1771: ARTEMIS-1600 Support masked passwords in boots...

[gaohoward]

Github user gaohoward commented on the issue:

https://github.com/apache/activemq-artemis/pull/1771
  
@jbertram good point. I think I can do that. Do you think we still need to 
support "mask-password" for backward compatibility?


---

[GitHub] activemq-artemis pull request #1770: ARTEMIS-1599 fixing compatibility with ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1770


---

[GitHub] activemq-artemis issue #1747: [WIP] NO-JIRA DISCUSS Replica use operationcon...

[shoukunhuai]

Github user shoukunhuai commented on the issue:

https://github.com/apache/activemq-artemis/pull/1747
  
@jbertram sure, i will close it, and thanks all.


---

[GitHub] activemq-artemis pull request #1747: [WIP] NO-JIRA DISCUSS Replica use opera...

[shoukunhuai]

Github user shoukunhuai closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1747


---

[GitHub] activemq-artemis issue #1747: [WIP] NO-JIRA DISCUSS Replica use operationcon...

[andytaylor]

Github user andytaylor commented on the issue:

https://github.com/apache/activemq-artemis/pull/1747
  
Yes

On 11 Jan 2018 19:52, "Justin Bertram"  wrote:

> Given the discussion here my understanding is that this PR should be
> closed. Are we in agreement?
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> 
,
> or mute the thread
> 

> .
>



---

[GitHub] activemq-artemis pull request #1774: ARTEMIS-1602 avoid potential NPE if pro...

[jbertram]

GitHub user jbertram opened a pull request:

https://github.com/apache/activemq-artemis/pull/1774

ARTEMIS-1602 avoid potential NPE if property is null



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-1602

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1774.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1774


commit addd66837dea52fe8b7cff6d06145a92ca930b06
Author: Justin Bertram 
Date:   2018-01-11T21:06:01Z

ARTEMIS-1602 avoid potential NPE if property is null




---

[GitHub] activemq-artemis issue #1756: [ARTEMIS-1590] Properties-based SQLProvider

[franz1981]

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/1756
  
@mtaylor @jmesnil 
I've run the CI tests and it seems good enough to me, I'll merge it 
tomorrow (in few hours), probably would be good to squash some commits to make 
it more compact


---

[GitHub] activemq-artemis issue #1742: ARTEMIS-1570 Flush appendExecutor before take ...

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1742
  
I didn't have the time for it yet.. still working on compatibility issues.


---

[GitHub] activemq-artemis issue #1757: ARTEMIS-1586 Reduce GC pressure due to String ...

[franz1981]

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/1757
  
@michaelandrepearce @clebertsuconic 
First benchs seems promising: I've used the Artemis master vs this patched 
version with 1 GB (-Xms -Xmx) of heap...
master version:

![image](https://user-images.githubusercontent.com/13125299/34845507-5376093c-f715-11e7-98cb-501390e26a80.png)


PR version:

![image](https://user-images.githubusercontent.com/13125299/34845395-ff0e75a0-f714-11e7-8d07-8021479ff9f8.png)

322 vs 215 Minor GCs and about half of the time sent into GC.
I need to perform some checks on thoughput and the client, but I'm very 
pleased by the results, wdyt? 



---

[GitHub] activemq-artemis issue #1742: ARTEMIS-1570 Flush appendExecutor before take ...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/1742
  
@clebertsuconic, what's the status of this?


---

[GitHub] activemq-artemis issue #1747: [WIP] NO-JIRA DISCUSS Replica use operationcon...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/1747
  
Given the discussion here my understanding is that this PR should be 
closed.  Are we in agreement?


---

[GitHub] activemq-artemis issue #1766: ARTEMIS-1596 STOMP consumer/producer auto-crea...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/1766
  
Your assumption is correct.  Do not auto-create the queue if the 
routing-type is MULTICAST.


---

[GitHub] activemq-artemis issue #1771: ARTEMIS-1600 Support masked passwords in boots...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/1771
  
Aside from the failing tests this looks OK.  

That said, I would love to see us move all our password masking to use the 
"ENC()" syntax instead of using boolean "mask-password" attributes 
everywhere if possible.  This is done for the properties login module and it's 
very clean.  If the text follows the pattern then it should be treated as 
masked otherwise it shouldn't.


---

[GitHub] activemq-artemis issue #1766: ARTEMIS-1596 STOMP consumer/producer auto-crea...

[jostbg]

Github user jostbg commented on the issue:

https://github.com/apache/activemq-artemis/pull/1766
  
@jbertram before I do so, I got one question. The original code was a bit 
unclear so I did some guessing, but should the queue only auto-created when the 
"address" routing type is not MULTICAST or always, i.e. is this assumption 
correct: 
https://github.com/apache/activemq-artemis/pull/1766/commits/3d0680e351db6cac65d087f33326405860961507#diff-2be6e6baef830595c16a9daa3d951615R283


---

[GitHub] activemq-artemis issue #1766: ARTEMIS-1596 STOMP consumer/producer auto-crea...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/1766
  
You should squash these commits together into a single commit and also add 
a test to reproduce the failure and verify the fix.


---

[GitHub] activemq-artemis pull request #1767: [ARTEMIS-1597] validate non null callba...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1767


---

[GitHub] activemq-artemis issue #1756: [ARTEMIS-1590] Properties-based SQLProvider

[franz1981]

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/1756
  
@mtaylor @jmesnil Before merging it I will re-run a CI round on it first: 
can't say but I couldn't check the current (seems ailed) Jenkins results


---

[GitHub] activemq-artemis pull request #1772: ARTEMIS-1601 Prevent NPE in StompSessio...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1772


---

[GitHub] activemq-artemis issue #1772: ARTEMIS-1601 Prevent NPE in StompSession#sendM...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/1772
  
I'll buy that.


---

[GitHub] activemq-artemis issue #1772: ARTEMIS-1601 Prevent NPE in StompSession#sendM...

[jostbg]

Github user jostbg commented on the issue:

https://github.com/apache/activemq-artemis/pull/1772
  
I wonder if that may be a race condition between StompSession#disconnect 
and StompSession#sendMessage, i.e. if a disconnect happens while sendMessage is 
being executed or something.


---

[GitHub] activemq-artemis issue #1772: ARTEMIS-1601 Prevent NPE in StompSession#sendM...

[jostbg]

Github user jostbg commented on the issue:

https://github.com/apache/activemq-artemis/pull/1772
  
The NPEs occur that's why I opened this PR. Since they are only logged in 
debug level I only saw them while debugging some stomp issue I had.

Throwing an exception is a relatively expensive operation in the JVM 
because of the stacktrace information that needs to be generated, so in cases 
where it is know that a null value could be returned it one should not rely on 
an NPE to be catched.


---

[GitHub] activemq-artemis issue #1772: ARTEMIS-1601 Prevent NPE in StompSession#sendM...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/1772
  
IMO, it's less clean because now there are 2 places which are returning 0 
in case of an error.  In any case, it's really not a big deal.

One additional question here...Is this NPE mainly theoretical or is there a 
specific use-case which triggers it?  If the former then I'm even less in favor 
of merging the PR.  If the latter then it would be worth adding a test or maybe 
just describing the use-case in the commit message.


---

[GitHub] activemq-artemis issue #1772: ARTEMIS-1601 Prevent NPE in StompSession#sendM...

[michaelandrepearce]

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1772
  
+1 I think It’s cleaner than relying exception to occur


---

[GitHub] activemq-artemis issue #1772: ARTEMIS-1601 Prevent NPE in StompSession#sendM...

[jbertram]

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/1772
  
I'm not sure this is actually necessary.  `java.lang.NullPointerException` 
extends `java.lang.RuntimeException` which in turn extends 
`java.lang.Exception` which is already being caught for this `try` block and 
returning 0.


---

[GitHub] activemq-artemis pull request #1768: Use same name for SslHandler as accepto...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1768


---

[GitHub] activemq-artemis pull request #1769: ARTEMIS-1576 Fix test that was broken w...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1769


---

ActiveMQ not able to handle messages > 100MB

[TarunpreetKaur]

Hi team,

We are not able to post a message greater than 100 mb from PeopleSoft to
ActiveMQ. Below is the error we are getting at PeopleSoft end:

*PublicationContractManager::ProcessError/RetryResponse(): 'Integration
Gateway: No response received from Gateway (158,10829)'.

Integration Gateway: No response received from Gateway*

The xml message never reaches ActiveMQ from PeopleSoft.

Thanks and Regards,
Tarunpreet Kaur






--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html

Re: [DISCUSS] Artemis Advisory Support

[Christopher Shannon]

I think using the notification support is fine but just wondering from the
standpoint of backwards compatibility if someone has software already
listening for OpenWire advisories.  However I do agree it would be a pain
to have to support 2 types.

On Wed, Jan 10, 2018 at 9:25 AM, Andy Taylor  wrote:

> definitely expand on the notifications already there, It wouldnt make sens
> to have 2 different implementations. What we also would need to do is
> replace the current advisory support that is built into the Openwire
> protocol with this.
>
> On 10 January 2018 at 13:19, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
> > One thing that is missing is 5.x style advisory support so I wanted to
> > discuss how we can add that.  The two ideas I had were to either expand
> on
> > the notification service support that already exists (ie add more
> > notification types) or to implement it using the plugin API.
> >
> > The easiest thing would be to just add new notification types to match
> > existing advisory messages that were in 5.x.  This uses the Core protocol
> > and would be different addresses.  I'm not sure if it also makes sense to
> > try and have a plugin that will also publish OpenWire style advisory
> > messages to the legacy 5.x topics as well.
> >
> > What do you guys think?
> >
>

[GitHub] activemq-artemis pull request #1759: [ARTEMIS-1241] check for FQQN and autoc...

[gtully]

Github user gtully commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1759#discussion_r160949474
  
--- Diff: 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/openwire/FQQNOpenWireTest.java
 ---
@@ -315,13 +314,13 @@ public void testVirtualTopicFQQN() throws Exception {
}
 
@Test
-   @Ignore("need to figure auto bindings creation")
public void testVirtualTopicFQQNAutoCreate() throws Exception {
   Connection exConn = null;
 
   SimpleString topic = new SimpleString("VirtualTopic.Orders");
   SimpleString subscriptionQ = new SimpleString("Consumer.A");
 
+  // defaults are false via test setUp
--- End diff --

thanks @mtaylor  - I see, that getDefaultAddressRoutingType should only be 
used by auto address creation. The queue routing type needs to be figured out 
from the address.


---

[GitHub] activemq-artemis pull request #1759: [ARTEMIS-1241] check for FQQN and autoc...

[mtaylor]

Github user mtaylor commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1759#discussion_r160925550
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
 ---
@@ -2810,19 +2810,27 @@ public Queue createQueue(final SimpleString address,
 
   final QueueConfig.Builder queueConfigBuilder;
 
-  final SimpleString addressToUse = address == null ? queueName : 
address;
+  RoutingType routingTypeToUse = (routingType == null ? 
ActiveMQDefaultConfiguration.getDefaultRoutingType() : routingType);
+  SimpleString queueNameToUse = queueName;
+  SimpleString addressToUse = address == null ? queueName : address;
+  if (CompositeAddress.isFullyQualified(address.toString())) {
+ CompositeAddress compositeAddress = 
CompositeAddress.getQueueName(address.toString());
+ addressToUse = new SimpleString(compositeAddress.getAddress());
+ queueNameToUse = new 
SimpleString(compositeAddress.getQueueName());
+ AddressSettings as = 
getAddressSettingsRepository().getMatch(addressToUse.toString());
+ routingTypeToUse = as.getDefaultAddressRoutingType();
--- End diff --

The routing type needs to come from the address.  If the address doesn't 
exist, then it should be auto-created before the queue is created.


---

[GitHub] activemq-artemis pull request #1759: [ARTEMIS-1241] check for FQQN and autoc...

[mtaylor]

Github user mtaylor commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1759#discussion_r160926081
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
 ---
@@ -2834,7 +2842,7 @@ public Queue createQueue(final SimpleString address,
  throw 
ActiveMQMessageBundle.BUNDLE.invalidRoutingTypeForAddress(routingType, 
info.getName().toString(), info.getRoutingTypes());
   }
 
-  final QueueConfig queueConfig = 
queueConfigBuilder.filter(filter).pagingManager(pagingManager).user(user).durable(durable).temporary(temporary).autoCreated(autoCreated).routingType(routingType).maxConsumers(maxConsumers).purgeOnNoConsumers(purgeOnNoConsumers).build();
+  final QueueConfig queueConfig = 
queueConfigBuilder.filter(filter).pagingManager(pagingManager).user(user).durable(durable).temporary(temporary).autoCreated(autoCreated).routingType(routingTypeToUse).maxConsumers(maxConsumers).purgeOnNoConsumers(purgeOnNoConsumers).build();
--- End diff --

The routing type should be decided by the protocol handler and passed in.  


---

[GitHub] activemq-artemis pull request #1759: [ARTEMIS-1241] check for FQQN and autoc...

[mtaylor]

Github user mtaylor commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1759#discussion_r160945016
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
 ---
@@ -2810,19 +2810,27 @@ public Queue createQueue(final SimpleString address,
 
   final QueueConfig.Builder queueConfigBuilder;
 
-  final SimpleString addressToUse = address == null ? queueName : 
address;
+  RoutingType routingTypeToUse = (routingType == null ? 
ActiveMQDefaultConfiguration.getDefaultRoutingType() : routingType);
--- End diff --

This logic should live in the OpenWire protocol manager.


---

[GitHub] activemq-artemis pull request #1759: [ARTEMIS-1241] check for FQQN and autoc...

[mtaylor]

Github user mtaylor commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1759#discussion_r160945285
  
--- Diff: 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/openwire/FQQNOpenWireTest.java
 ---
@@ -315,13 +314,13 @@ public void testVirtualTopicFQQN() throws Exception {
}
 
@Test
-   @Ignore("need to figure auto bindings creation")
public void testVirtualTopicFQQNAutoCreate() throws Exception {
   Connection exConn = null;
 
   SimpleString topic = new SimpleString("VirtualTopic.Orders");
   SimpleString subscriptionQ = new SimpleString("Consumer.A");
 
+  // defaults are false via test setUp
--- End diff --

We should test the case where an address already exists and the default 
type is ANYCAST.


---

[GitHub] activemq-artemis pull request #1773: ARTEMIS-1589 ActiveMQProtonRemotingConn...

[jostbg]

GitHub user jostbg opened a pull request:

https://github.com/apache/activemq-artemis/pull/1773

ARTEMIS-1589 ActiveMQProtonRemotingConnection#getClientID() now returns 
remote client Id...

...instead of server client Id

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jostbg/activemq-artemis ARTEMIS-1589

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1773.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1773


commit 47dd6f19c0ead5f01a526ecd941f2a32dace8f0d
Author: jostbg <35264802+jostbg@...>
Date:   2018-01-11T11:23:33Z

ARTEMIS-1589 ActiveMQProtonRemotingConnection#getClientID() now returns 
remote client Id instead of server client Id




---

[GitHub] activemq-artemis pull request #1772: ARTEMIS-1601 Prevent NPE in StompSessio...

[jostbg]

GitHub user jostbg opened a pull request:

https://github.com/apache/activemq-artemis/pull/1772

ARTEMIS-1601 Prevent NPE in StompSession#sendMessage



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jostbg/activemq-artemis ARTEMIS-1601

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1772.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1772


commit 185983d4dff8e9d256fc65cb2e1fe0e7b12ec8fb
Author: jostbg <35264802+jostbg@...>
Date:   2018-01-11T11:16:35Z

ARTEMIS-1601 Prevent NPE in StompSession#sendMessage




---

[GitHub] activemq-artemis pull request #1754: ARTEMIS-1576 couple more tests for good...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1754


---

[GitHub] activemq-artemis pull request #1749: ARTEMIS-1579 browsing messages in hawti...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1749


---

[GitHub] activemq-artemis issue #1749: ARTEMIS-1579 browsing messages in hawtio conso...

[mtaylor]

Github user mtaylor commented on the issue:

https://github.com/apache/activemq-artemis/pull/1749
  
@stanlyDoge Built and tested looks good.  Cheers.


---

[GitHub] activemq-artemis issue #1744: [ARTEMIS-1577] Address-settings policies aren'...

[mtaylor]

Github user mtaylor commented on the issue:

https://github.com/apache/activemq-artemis/pull/1744
  
@shailendra14k This has been handled using two approaches internally which 
might have caused some confusion.  But, there is an acceptor setting 
anycastPrefix and multicastPrefix that does what you've put here.  

Try appending the following to you acceptor 
"anycastPrefix=jms.queue.;multicastPrefix=jms.topic."


---

[GitHub] activemq-artemis issue #1770: ARTEMIS-1599 fixing compatibility with 1.x exp...

[mtaylor]

Github user mtaylor commented on the issue:

https://github.com/apache/activemq-artemis/pull/1770
  
Couple of test failures:

Test Result (2 failures / +2)

org.apache.activemq.artemis.tests.compatibility.ExportImportTest.testSendReceive[server=null,
 producer=ARTEMIS-155, consumer=ARTEMIS-SNAPSHOT]


org.apache.activemq.artemis.tests.compatibility.ExportImportTest.testSendReceive[server=null,
 producer=ARTEMIS-SNAPSHOT, consumer=ARTEMIS-SNAPSHOT]


---

Call for Presentations FOSS Backstage open

[Isabel Drost-Fromm]

Hi,

As announced on Berlin Buzzwords we (that is Isabel Drost-Fromm, Stefan
Rudnitzki as well as the eventing team over at newthinking communications GmbH)
are working on a new conference in summer in Berlin. The name of this new
conference will be "FOSS Backstage". Backstage comprises all things
FOSS governance, open collaboration and how to build and manage communities
within the open source space.


Submission URL: https://foss-backstage.de/call-papers 

The event will comprise presentations on all things FOSS governance,
decentralised decision making, open collaboration. We invite you to submit talks
on the topics: FOSS project governance, collaboration, community management.
Asynchronous/ decentralised decision making.  Vendor neutrality in FOSS,
sustainable FOSS, cross team collaboration.  Dealing with poisonous people.
Project growth and hand-over. Trademarks. Strategic licensing.  While it's
primarily targeted at contributions from FOSS people, we would love to also
learn more on how typical FOSS collaboration models work well within
enterprises. Closely related topics not explicitly listed above are welcome. 

Important Dates (all dates in GMT +2)

Submission deadline: February 18th, 2018.

Conference: June, 13th/14th, 2018


High quality talks are called for, ranging from principles to practice. We are
looking for real world case studies, background on the social architecture of
specific projects and a deep dive into cross community collaboration.
Acceptance notifications will be sent out soon after the submission deadline.
Please include your name, bio and email, the title of the talk, a brief abstract
in English language.

We have drafted the submission form to allow for regular talks, each 45 min in
length. However you are free to submit your own ideas on how to support the
event: If you would like to take our attendees out to show them your favourite
bar in Berlin, please submit this offer through the CfP form.  If you are
interested in sponsoring the event (e.g. we would be happy to provide videos
after the event, free drinks for attendees as well as an after-show party),
please contact us.

Schedule and further updates on the event will be published soon on the event
web page.

Please re-distribute this CfP to people who might be interested.

 Contact us at:
 newthinking communications GmbH
 Schoenhauser Allee 6/7
 10119 Berlin, Germany
 i...@foss-backstage.de


Looking forward to meeting you all in person in summer :) I would love to see 
all those
tracks filled with lots of valuable talks on the Apache Way, on how we work,
on how the incubator works, on how being a 501(c3) influences how people get 
involved
and projects are being run, on how being a member run organisation is different,
on merit for life, on growing communities, on things gone great - and things
gone entirely wrong in the ASF's history, on how to interact with Apache
projects as a corporation and everything else you can think of.


Isabel


-- 
Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most 
likely involving some kind of mobile connection only.)