[jira] [Closed] (ARTEMIS-1640) JDBC NodeManager tests have to be customizable to run on different DBMS
[ https://issues.apache.org/jira/browse/ARTEMIS-1640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro closed ARTEMIS-1640. Resolution: Fixed > JDBC NodeManager tests have to be customizable to run on different DBMS > --- > > Key: ARTEMIS-1640 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1640 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > > NettyFailoverTest and JdbcLeaseLockTest can be made configurable in order to > run on different DBMS, like other ActiveMQTestBase tests already do. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1702) ConcurrentLongHashMap and ConcurrentLongHashSet should avoid volatile set cost on put/remove
[ https://issues.apache.org/jira/browse/ARTEMIS-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro closed ARTEMIS-1702. Resolution: Fixed > ConcurrentLongHashMap and ConcurrentLongHashSet should avoid volatile set > cost on put/remove > > > Key: ARTEMIS-1702 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1702 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.5.0 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.5.0 > > > ConcurrentLongHashSet/HashMap are making use of unecessary volatile store of > size/capacity for modifier methods. > The current JVM implementation of volatile store for multicore x86 is making > use of a StoreLoad barrier for this operation: the most expensive one. > These volatile stores could be replaced by plain stores/lazySet ones with no > effects on the correctness of those methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1656) OpenWire scalability improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro closed ARTEMIS-1656. Resolution: Fixed Fix Version/s: 2.5.0 > OpenWire scalability improvements > - > > Key: ARTEMIS-1656 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1656 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.5.0 > > > OpenWire is using the synchronized OpenWireFormat instance belonging to > OpenWireProtocolManager: it won't allow to scale with the number of > connections. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1608) OpenWire throws AMQ119018: Binding already exists
[ https://issues.apache.org/jira/browse/ARTEMIS-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro closed ARTEMIS-1608. Resolution: Duplicate Fix Version/s: 2.5.0 > OpenWire throws AMQ119018: Binding already exists > - > > Key: ARTEMIS-1608 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1608 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Fix For: 2.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ARTEMIS-1709) Can't send large messages with AMQP
[
https://issues.apache.org/jira/browse/ARTEMIS-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379819#comment-16379819
]
Simon Chalmers edited comment on ARTEMIS-1709 at 2/28/18 6:07 AM:
--
Example tester client code, using Amqp.Net Lite.
var connectionFactory = new ConnectionFactory();
var connection = await connectionFactory.CreateAsync(new
Address("amqp://artemis:simetraehcapa@linuxhost"));
var session = new Session(connection);
var senderLink = new SenderLink(session, "sender-link",
"queue.in.my-service.test-request");
var rng = new Random();
var messageContent = new byte[60];
rng.NextBytes(messageContent);
senderLink.Send(new Message(messageContent));
wait senderLink.CloseAsync();
await session.CloseAsync();
await connection.CloseAsync();
was (Author: auskeptic):
Example tester client code, using Amqp.Net Lite.
var connectionFactory = new ConnectionFactory();
var connection = await connectionFactory.CreateAsync(new
Address("amqp://artemis:simetraehcapa@linuxhost"));
var session = new Session(connection);
var senderLink = new SenderLink(session, "sender-link",
"queue.in.my-service.test-request");
var rng = new Random();
var messageContent = new byte[60];
rng.NextBytes(messageContent);
senderLink.Send(new Message(messageContent));
await senderLink.CloseAsync();
await session.CloseAsync();
await connection.CloseAsync();
> Can't send large messages with AMQP
> ---
>
> Key: ARTEMIS-1709
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1709
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.4.0
> Environment: broker.xml file attached.
>Reporter: Simon Chalmers
>Priority: Major
> Fix For: 2.3.0
>
> Attachments: broker.xml
>
>
> Sending a single message using AMQP to a queue where the size of the single
> message is 501741 bytes errors out.
> Sending the same single message to version 2.3.0 of Artemis does not result
> in the same error and is sent successfully.
> Error:
>
> Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on
> the Server''s Session
> at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds)
> at
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext()
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext()
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
> task)
> at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in
> C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
> task)
> at MI.Messaging.AmqpNetLite.Test.Program.(String[] args)
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ARTEMIS-1709) Can't send large messages with AMQP
[
https://issues.apache.org/jira/browse/ARTEMIS-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379819#comment-16379819
]
Simon Chalmers edited comment on ARTEMIS-1709 at 2/28/18 6:06 AM:
--
Example tester client code, using Amqp.Net Lite.
var connectionFactory = new ConnectionFactory();
var connection = await connectionFactory.CreateAsync(new
Address("amqp://artemis:simetraehcapa@linuxhost"));
var session = new Session(connection);
var senderLink = new SenderLink(session, "sender-link",
"queue.in.my-service.test-request");
var rng = new Random();
var messageContent = new byte[60];
rng.NextBytes(messageContent);
senderLink.Send(new Message(messageContent));
await senderLink.CloseAsync();
await session.CloseAsync();
await connection.CloseAsync();
was (Author: auskeptic):
Example tester client code, using Amqp.Net Lite.
var connectionFactory = new ConnectionFactory();
var connection = await connectionFactory.CreateAsync(new
Address("amqp://artemis:simetraehcapa@linuxhost"));
var session = new Session(connection);
var senderLink = new SenderLink(session, "sender-link",
"queue.in.my-service.test-request");
var rng = new Random();
var messageContent = new byte[6];
rng.NextBytes(messageContent);
senderLink.Send(new Message(messageContent));
await senderLink.CloseAsync();
await session.CloseAsync();
await connection.CloseAsync();
> Can't send large messages with AMQP
> ---
>
> Key: ARTEMIS-1709
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1709
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.4.0
> Environment: broker.xml file attached.
>Reporter: Simon Chalmers
>Priority: Major
> Fix For: 2.3.0
>
> Attachments: broker.xml
>
>
> Sending a single message using AMQP to a queue where the size of the single
> message is 501741 bytes errors out.
> Sending the same single message to version 2.3.0 of Artemis does not result
> in the same error and is sent successfully.
> Error:
>
> Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on
> the Server''s Session
> at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds)
> at
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext()
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext()
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
> task)
> at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in
> C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
> task)
> at MI.Messaging.AmqpNetLite.Test.Program.(String[] args)
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1705) Queue stop deliver after remove all paged message over JMX
[ https://issues.apache.org/jira/browse/ARTEMIS-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379822#comment-16379822 ] ASF GitHub Bot commented on ARTEMIS-1705: - GitHub user morefuntang opened a pull request: https://github.com/apache/activemq-artemis/pull/1907 ARTEMIS-1705 Queue stop deliver after remove all paged message over JMX I remove all messages in Queue via removeAllMessages in JMX After removed all paged message, queue stopped deliver message. During debug, we found that memory size of the queue is more then 2 pages size, but both message references and intermediate message references are empty. The deliver runner will not depage because queue memory size is over max size. You can merge this pull request into a Git repository by running: $ git pull https://github.com/morefuntang/activemq-artemis live-only-2.4.0 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/1907.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 #1907 commit 430648661db6871e3f6d3cbfa42d52e4cad6f24c Author: 17103355 <17103355@...> Date: 2018-02-28T03:38:00Z Only messages from MessageReferences are subtracted from the queueMemorySize commit bc6084ba5a14f73ef7d67d679df043bbb2412cbd Author: 17103355 <17103355@...> Date: 2018-02-28T03:46:08Z Only messages from MessageReferences are subtracted from the queueMemorySize > Queue stop deliver after remove all paged message over JMX > -- > > Key: ARTEMIS-1705 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1705 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.4.0 >Reporter: tang pu >Priority: Minor > > I remove all messages in Queue via removeAllMessages in JMX > After removed all paged message, queue stopped deliver message. > During debug, we found that memory size of the queue is more then 2 pages > size, but both message references and intermediate message references are > empty. > The deliver runner will not depage because queue memory size is over max size. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1709) Can't send large messages with AMQP
[
https://issues.apache.org/jira/browse/ARTEMIS-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379819#comment-16379819
]
Simon Chalmers commented on ARTEMIS-1709:
-
Example tester client code, using Amqp.Net Lite.
var connectionFactory = new ConnectionFactory();
var connection = await connectionFactory.CreateAsync(new
Address("amqp://artemis:simetraehcapa@linuxhost"));
var session = new Session(connection);
var senderLink = new SenderLink(session, "sender-link",
"queue.in.my-service.test-request");
var rng = new Random();
var messageContent = new byte[6];
rng.NextBytes(messageContent);
senderLink.Send(new Message(messageContent));
await senderLink.CloseAsync();
await session.CloseAsync();
await connection.CloseAsync();
> Can't send large messages with AMQP
> ---
>
> Key: ARTEMIS-1709
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1709
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.4.0
> Environment: broker.xml file attached.
>Reporter: Simon Chalmers
>Priority: Major
> Fix For: 2.3.0
>
> Attachments: broker.xml
>
>
> Sending a single message using AMQP to a queue where the size of the single
> message is 501741 bytes errors out.
> Sending the same single message to version 2.3.0 of Artemis does not result
> in the same error and is sent successfully.
> Error:
>
> Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on
> the Server''s Session
> at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds)
> at
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext()
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext()
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
> task)
> at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in
> C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
> task)
> at MI.Messaging.AmqpNetLite.Test.Program.(String[] args)
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1709) Can't send large messages with AMQP
[ https://issues.apache.org/jira/browse/ARTEMIS-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Chalmers updated ARTEMIS-1709: Description: Sending a single message using AMQP to a queue where the size of the single message is 501741 bytes errors out. Sending the same single message to version 2.3.0 of Artemis does not result in the same error and is sent successfully. Error: Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on the Server''s Session at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds) at MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54 — End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102 — End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131 — End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at MI.Messaging.AmqpNetLite.Test.Program.(String[] args) was: Sending a single message using AMQP to a queue of mesage size 501741 bytes errors. Sending the same single message to version 2.3.0 of Artemis does not result in the same error and is sent successfully. Error: Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on the Server''s Session at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds) at MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at MI.Messaging.AmqpNetLite.Test.Program.(String[] args) > Can't send large messages with AMQP > --- > > Key: ARTEMIS-1709 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1709 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.4.0 > Environment: broker.xml file attached. >Reporter: Simon Chalmers >Priority: Major > Fix For: 2.3.0 > > Attachments: broker.xml > > > Sending a single message using AMQP to a queue where the size of the single > message is 501741 bytes errors out. > Sending the same single message to version 2.3.0 of Artemis does not result > in the same error and is sent successfully. > Error: > > Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on > the Server''s Session > at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds) > at > MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() > in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging > Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54 > — End of stack trace from previous location where exception was thrown — > at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() > at > MI.Messaging.Amq
[jira] [Created] (ARTEMIS-1709) Can't send large messages with AMQP
Simon Chalmers created ARTEMIS-1709: --- Summary: Can't send large messages with AMQP Key: ARTEMIS-1709 URL: https://issues.apache.org/jira/browse/ARTEMIS-1709 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.4.0 Environment: broker.xml file attached. Reporter: Simon Chalmers Fix For: 2.3.0 Attachments: broker.xml Sending a single message using AMQP to a queue of mesage size 501741 bytes errors. Sending the same single message to version 2.3.0 of Artemis does not result in the same error and is sent successfully. Error: Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on the Server''s Session at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds) at MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at MI.Messaging.AmqpNetLite.Test.Program.(String[] args) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1708) Missing documentation on queue attributes
[ https://issues.apache.org/jira/browse/ARTEMIS-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1708. - Resolution: Duplicate > Missing documentation on queue attributes > - > > Key: ARTEMIS-1708 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1708 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.3.0, 2.4.0 >Reporter: Simon Chalmers >Priority: Minor > > Queue Attributes documentation is blank for 2.3.0 / latest: > [https://activemq.apache.org/artemis/docs/latest/queue-attributes.html] > Should be similar to 1.5.5, I imagine: > [https://activemq.apache.org/artemis/docs/1.5.5/queue-attributes.html] > Same result in Google Chrome, Edge, so not a browser related display issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1708) Missing documentation on queue attributes
Simon Chalmers created ARTEMIS-1708: --- Summary: Missing documentation on queue attributes Key: ARTEMIS-1708 URL: https://issues.apache.org/jira/browse/ARTEMIS-1708 Project: ActiveMQ Artemis Issue Type: Improvement Affects Versions: 2.4.0, 2.3.0 Reporter: Simon Chalmers Queue Attributes documentation is blank for 2.3.0 / latest: [https://activemq.apache.org/artemis/docs/latest/queue-attributes.html] Should be similar to 1.5.5, I imagine: [https://activemq.apache.org/artemis/docs/1.5.5/queue-attributes.html] Same result in Google Chrome, Edge, so not a browser related display issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1706) Support wantClientAuth on NettyAcceptor
[ https://issues.apache.org/jira/browse/ARTEMIS-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379619#comment-16379619 ] ASF GitHub Bot commented on ARTEMIS-1706: - Github user cshannon commented on the issue: https://github.com/apache/activemq-artemis/pull/1903 I am going to update my PR with Tim’s suggestion to have it match 5.x and rebase in the morning > Support wantClientAuth on NettyAcceptor > --- > > Key: ARTEMIS-1706 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1706 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 2.5.0 > > > Currently an acceptor can be configured for 2 way SSL authentication by > setting needClientAuth to true. It is also useful to be able to set > wantClientAuth to be true so that two way SSL is requested but isn't required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1706) Support wantClientAuth on NettyAcceptor
[ https://issues.apache.org/jira/browse/ARTEMIS-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379617#comment-16379617 ] ASF GitHub Bot commented on ARTEMIS-1706: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1903 @cshannon rebase it... are you addressing @tabish121's comments or that doesn't apply? > Support wantClientAuth on NettyAcceptor > --- > > Key: ARTEMIS-1706 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1706 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 2.5.0 > > > Currently an acceptor can be configured for 2 way SSL authentication by > setting needClientAuth to true. It is also useful to be able to set > wantClientAuth to be true so that two way SSL is requested but isn't required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1707) [openwire] error on create of queue if another connection creates one of the same name
[
https://issues.apache.org/jira/browse/ARTEMIS-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved ARTEMIS-1707.
---
Resolution: Fixed
Tested with patch applied and cannot reproduce the error
> [openwire] error on create of queue if another connection creates one of the
> same name
> --
>
> Key: ARTEMIS-1707
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1707
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 2.4.0
> Environment: OpenWire protocol head using ActiveMQ JMS client
>Reporter: Timothy Bish
>Priority: Major
> Fix For: 2.5.0
>
>
> When two OpenWire client resources (Producer or Consumer) attempt to create a
> Queue destination (generally from two different connections) at the same time
> the following exception can be seen:
> {noformat}
> java.lang.RuntimeException: javax.jms.JMSException:
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
> Binding already exists LocalQueueBinding [address=q2,
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
> temp=false]@6ca8009b, filter=null, name=q2,
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
> at net.ssorj.quiver.Client.run(QuiverArrowJms.java:126)
> at net.ssorj.quiver.QuiverArrowJms.doMain(QuiverArrowJms.java:67)
> at net.ssorj.quiver.QuiverArrowJms.main(QuiverArrowJms.java:29)
> Caused by: javax.jms.JMSException:
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
> Binding already exists LocalQueueBinding [address=q2,
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
> temp=false]@6ca8009b, filter=null, name=q2,
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1399)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1428)
> at
> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:2086)
> at
> org.apache.activemq.ActiveMQMessageProducer.(ActiveMQMessageProducer.java:124)
> at
> org.apache.activemq.ActiveMQSession.createProducer(ActiveMQSession.java:1117)
> at net.ssorj.quiver.Client.sendMessages(QuiverArrowJms.java:136)
> at net.ssorj.quiver.Client.run(QuiverArrowJms.java:113)
> ... 2 more
> Caused by: java.lang.Throwable:
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
> Binding already exists LocalQueueBinding [address=q2,
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
> temp=false]@6ca8009b, filter=null, name=q2,
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
> at
> org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addBinding(SimpleAddressManager.java:85)
> at
> org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:90)
> at
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.addBinding(PostOfficeImpl.java:599)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:2765)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:1676)
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:588)
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:668)
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.addDestination(OpenWireConnection.java:768)
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddProducer(OpenWireConnection.java:1086)
> at org.apache.activemq.command.ProducerInfo.visit(ProducerInfo.java:108)
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:289)
> at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:646)
> at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at
> io.netty.channel.AbstractCha
[jira] [Commented] (ARTEMIS-1698) Support "instance" web deployments
[ https://issues.apache.org/jira/browse/ARTEMIS-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379518#comment-16379518 ] ASF GitHub Bot commented on ARTEMIS-1698: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/1889 > Support "instance" web deployments > -- > > Key: ARTEMIS-1698 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1698 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > > Currently any web application deployment to the embedded Jetty instance must > be done via the "web" directory of the Artemis "home" installation. This > includes things like the web console or REST interface. We should support > deployments in the "web" directory of the Artemis "instance" as well so > instances can have better control over what web applications they deploy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1698) Support "instance" web deployments
[ https://issues.apache.org/jira/browse/ARTEMIS-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379517#comment-16379517 ] ASF subversion and git services commented on ARTEMIS-1698: -- Commit d552e4d2c8b835e5f973ca13856e199488b0ccbb in activemq-artemis's branch refs/heads/master from [~jbertram] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=d552e4d ] ARTEMIS-1698 support 'instance' web deployments > Support "instance" web deployments > -- > > Key: ARTEMIS-1698 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1698 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > > Currently any web application deployment to the embedded Jetty instance must > be done via the "web" directory of the Artemis "home" installation. This > includes things like the web console or REST interface. We should support > deployments in the "web" directory of the Artemis "instance" as well so > instances can have better control over what web applications they deploy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1707) [openwire] error on create of queue if another connection creates one of the same name
[
https://issues.apache.org/jira/browse/ARTEMIS-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379510#comment-16379510
]
ASF GitHub Bot commented on ARTEMIS-1707:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/1905
> [openwire] error on create of queue if another connection creates one of the
> same name
> --
>
> Key: ARTEMIS-1707
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1707
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 2.4.0
> Environment: OpenWire protocol head using ActiveMQ JMS client
>Reporter: Timothy Bish
>Priority: Major
> Fix For: 2.5.0
>
>
> When two OpenWire client resources (Producer or Consumer) attempt to create a
> Queue destination (generally from two different connections) at the same time
> the following exception can be seen:
> {noformat}
> java.lang.RuntimeException: javax.jms.JMSException:
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
> Binding already exists LocalQueueBinding [address=q2,
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
> temp=false]@6ca8009b, filter=null, name=q2,
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
> at net.ssorj.quiver.Client.run(QuiverArrowJms.java:126)
> at net.ssorj.quiver.QuiverArrowJms.doMain(QuiverArrowJms.java:67)
> at net.ssorj.quiver.QuiverArrowJms.main(QuiverArrowJms.java:29)
> Caused by: javax.jms.JMSException:
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
> Binding already exists LocalQueueBinding [address=q2,
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
> temp=false]@6ca8009b, filter=null, name=q2,
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1399)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1428)
> at
> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:2086)
> at
> org.apache.activemq.ActiveMQMessageProducer.(ActiveMQMessageProducer.java:124)
> at
> org.apache.activemq.ActiveMQSession.createProducer(ActiveMQSession.java:1117)
> at net.ssorj.quiver.Client.sendMessages(QuiverArrowJms.java:136)
> at net.ssorj.quiver.Client.run(QuiverArrowJms.java:113)
> ... 2 more
> Caused by: java.lang.Throwable:
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
> Binding already exists LocalQueueBinding [address=q2,
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
> temp=false]@6ca8009b, filter=null, name=q2,
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
> at
> org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addBinding(SimpleAddressManager.java:85)
> at
> org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:90)
> at
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.addBinding(PostOfficeImpl.java:599)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:2765)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:1676)
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:588)
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:668)
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.addDestination(OpenWireConnection.java:768)
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddProducer(OpenWireConnection.java:1086)
> at org.apache.activemq.command.ProducerInfo.visit(ProducerInfo.java:108)
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:289)
> at
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:646)
> at
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChanne
[jira] [Commented] (ARTEMIS-1707) [openwire] error on create of queue if another connection creates one of the same name
[
https://issues.apache.org/jira/browse/ARTEMIS-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379506#comment-16379506
]
ASF subversion and git services commented on ARTEMIS-1707:
--
Commit 38fb17703b3479d1ef933b8f5a99e75f72166c96 in activemq-artemis's branch
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=38fb177 ]
ARTEMIS-1707 Check for already exists exceptions and ignore
For address and queue create check for the already exists exceptions and
ignore as another client might have just created the same
> [openwire] error on create of queue if another connection creates one of the
> same name
> --
>
> Key: ARTEMIS-1707
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1707
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 2.4.0
> Environment: OpenWire protocol head using ActiveMQ JMS client
>Reporter: Timothy Bish
>Priority: Major
> Fix For: 2.5.0
>
>
> When two OpenWire client resources (Producer or Consumer) attempt to create a
> Queue destination (generally from two different connections) at the same time
> the following exception can be seen:
> {noformat}
> java.lang.RuntimeException: javax.jms.JMSException:
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
> Binding already exists LocalQueueBinding [address=q2,
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
> temp=false]@6ca8009b, filter=null, name=q2,
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
> at net.ssorj.quiver.Client.run(QuiverArrowJms.java:126)
> at net.ssorj.quiver.QuiverArrowJms.doMain(QuiverArrowJms.java:67)
> at net.ssorj.quiver.QuiverArrowJms.main(QuiverArrowJms.java:29)
> Caused by: javax.jms.JMSException:
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
> Binding already exists LocalQueueBinding [address=q2,
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
> temp=false]@6ca8009b, filter=null, name=q2,
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1399)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1428)
> at
> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:2086)
> at
> org.apache.activemq.ActiveMQMessageProducer.(ActiveMQMessageProducer.java:124)
> at
> org.apache.activemq.ActiveMQSession.createProducer(ActiveMQSession.java:1117)
> at net.ssorj.quiver.Client.sendMessages(QuiverArrowJms.java:136)
> at net.ssorj.quiver.Client.run(QuiverArrowJms.java:113)
> ... 2 more
> Caused by: java.lang.Throwable:
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
> Binding already exists LocalQueueBinding [address=q2,
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
> temp=false]@6ca8009b, filter=null, name=q2,
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
> at
> org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addBinding(SimpleAddressManager.java:85)
> at
> org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:90)
> at
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.addBinding(PostOfficeImpl.java:599)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:2765)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:1676)
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:588)
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:668)
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.addDestination(OpenWireConnection.java:768)
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddProducer(OpenWireConnection.java:1086)
> at org.apache.activemq.command.ProducerInfo.visit(ProducerInfo.java:108)
> at
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:289)
> at
> org.apache.activemq.artemis.core.r
[jira] [Commented] (ARTEMIS-1707) [openwire] error on create of queue if another connection creates one of the same name
[
https://issues.apache.org/jira/browse/ARTEMIS-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379309#comment-16379309
]
ASF GitHub Bot commented on ARTEMIS-1707:
-
GitHub user tabish121 opened a pull request:
https://github.com/apache/activemq-artemis/pull/1905
ARTEMIS-1707 Check for already exists exceptions and ignore
For address and queue create check for the already exists exceptions and
ignore as another client might have just created the same
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/tabish121/activemq-artemis ARTEMIS-1707
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/1905.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 #1905
commit 38fb17703b3479d1ef933b8f5a99e75f72166c96
Author: Timothy Bish
Date: 2018-02-27T21:30:06Z
ARTEMIS-1707 Check for already exists exceptions and ignore
For address and queue create check for the already exists exceptions and
ignore as another client might have just created the same
> [openwire] error on create of queue if another connection creates one of the
> same name
> --
>
> Key: ARTEMIS-1707
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1707
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: OpenWire
>Affects Versions: 2.4.0
> Environment: OpenWire protocol head using ActiveMQ JMS client
>Reporter: Timothy Bish
>Priority: Major
> Fix For: 2.5.0
>
>
> When two OpenWire client resources (Producer or Consumer) attempt to create a
> Queue destination (generally from two different connections) at the same time
> the following exception can be seen:
> {noformat}
> java.lang.RuntimeException: javax.jms.JMSException:
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
> Binding already exists LocalQueueBinding [address=q2,
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
> temp=false]@6ca8009b, filter=null, name=q2,
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
> at net.ssorj.quiver.Client.run(QuiverArrowJms.java:126)
> at net.ssorj.quiver.QuiverArrowJms.doMain(QuiverArrowJms.java:67)
> at net.ssorj.quiver.QuiverArrowJms.main(QuiverArrowJms.java:29)
> Caused by: javax.jms.JMSException:
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
> Binding already exists LocalQueueBinding [address=q2,
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
> temp=false]@6ca8009b, filter=null, name=q2,
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
> at
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1399)
> at
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1428)
> at
> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:2086)
> at
> org.apache.activemq.ActiveMQMessageProducer.(ActiveMQMessageProducer.java:124)
> at
> org.apache.activemq.ActiveMQSession.createProducer(ActiveMQSession.java:1117)
> at net.ssorj.quiver.Client.sendMessages(QuiverArrowJms.java:136)
> at net.ssorj.quiver.Client.run(QuiverArrowJms.java:113)
> ... 2 more
> Caused by: java.lang.Throwable:
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
> Binding already exists LocalQueueBinding [address=q2,
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
> temp=false]@6ca8009b, filter=null, name=q2,
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
> at
> org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addBinding(SimpleAddressManager.java:85)
> at
> org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:90)
> at
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.addBinding(PostOfficeImpl.java:599)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:2765)
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:1676)
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:588)
>
[jira] [Commented] (ARTEMIS-1706) Support wantClientAuth on NettyAcceptor
[ https://issues.apache.org/jira/browse/ARTEMIS-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379306#comment-16379306 ] ASF GitHub Bot commented on ARTEMIS-1706: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1903 can you rebase against master? I have sent a fix to the JORAM tests.. this would be a helpful as a test as well. > Support wantClientAuth on NettyAcceptor > --- > > Key: ARTEMIS-1706 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1706 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 2.5.0 > > > Currently an acceptor can be configured for 2 way SSL authentication by > setting needClientAuth to true. It is also useful to be able to set > wantClientAuth to be true so that two way SSL is requested but isn't required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1700) Server stopped responding and killed itself while exiting paging state
[ https://issues.apache.org/jira/browse/ARTEMIS-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379301#comment-16379301 ] ASF GitHub Bot commented on ARTEMIS-1700: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/1904 > Server stopped responding and killed itself while exiting paging state > -- > > Key: ARTEMIS-1700 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1700 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.4.0 >Reporter: Qihong Xu >Priority: Major > Attachments: artemis.log > > > We are currently experiencing this error while running stress test on artemis. > > Basic configuration: > 1 broker ,1 topic, pub-sub mode. > Journal type = MAPPED. > Threadpool max size = 60. > > In order to test the throughput of artemis we use 300 producers and 300 > consumers. However we found that sometimes when artemis exit paging state, it > will stop responding and kill itself. This situatuion happened on some > specific servers. > > Details can be found in attached dump file. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1700) Server stopped responding and killed itself while exiting paging state
[ https://issues.apache.org/jira/browse/ARTEMIS-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379300#comment-16379300 ] ASF subversion and git services commented on ARTEMIS-1700: -- Commit 7e06a2b1922f40447cd2eff4f7147e4b7056ae1e in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=7e06a2b ] ARTEMIS-1700 Using IOExecutors for more IO tasks > Server stopped responding and killed itself while exiting paging state > -- > > Key: ARTEMIS-1700 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1700 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.4.0 >Reporter: Qihong Xu >Priority: Major > Attachments: artemis.log > > > We are currently experiencing this error while running stress test on artemis. > > Basic configuration: > 1 broker ,1 topic, pub-sub mode. > Journal type = MAPPED. > Threadpool max size = 60. > > In order to test the throughput of artemis we use 300 producers and 300 > consumers. However we found that sometimes when artemis exit paging state, it > will stop responding and kill itself. This situatuion happened on some > specific servers. > > Details can be found in attached dump file. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1706) Support wantClientAuth on NettyAcceptor
[ https://issues.apache.org/jira/browse/ARTEMIS-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379268#comment-16379268 ] ASF GitHub Bot commented on ARTEMIS-1706: - Github user tabish121 commented on a diff in the pull request: https://github.com/apache/activemq-artemis/pull/1903#discussion_r171066273 --- Diff: docs/user-manual/en/configuring-transports.md --- @@ -403,6 +403,15 @@ following additional properties: This property is only for an `acceptor`. It tells a client connecting to this acceptor that 2-way SSL is required. Valid values are `true` or `false`. Default is `false`. + +- `wantClientAuth` + +This property is only for an `acceptor`. It tells a client +connecting to this acceptor that 2-way SSL is requested but not required. +Valid values are `true` or `false`. Default is `false`. + +Note that this setting will override `needClientAuth` if both properties +are set to true. --- End diff -- I failed to read this before my previous comment but as before I'd have opted to go the other way on the choice and defaulted to need if both are there. For reference the 5.x code makes that choice as well when both are present on the URI > Support wantClientAuth on NettyAcceptor > --- > > Key: ARTEMIS-1706 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1706 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 2.5.0 > > > Currently an acceptor can be configured for 2 way SSL authentication by > setting needClientAuth to true. It is also useful to be able to set > wantClientAuth to be true so that two way SSL is requested but isn't required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1706) Support wantClientAuth on NettyAcceptor
[
https://issues.apache.org/jira/browse/ARTEMIS-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16379249#comment-16379249
]
ASF GitHub Bot commented on ARTEMIS-1706:
-
Github user tabish121 commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1903#discussion_r171060932
--- Diff:
artemis-server/src/main/java/org/apache/activemq/artemis/core/remoting/impl/netty/NettyAcceptor.java
---
@@ -468,8 +473,12 @@ public synchronized SslHandler
getSslHandler(ByteBufAllocator alloc) throws Exce
engine.setUseClientMode(false);
- if (needClientAuth)
+ if (needClientAuth) {
engine.setNeedClientAuth(true);
+ }
+ if (wantClientAuth) {
--- End diff --
I would probably do this in an else as the setting would override the need
option and if someone did something silly like specify both I'd generally
prefer it chose the stronger of the two and setting want after need overrides
it.
> Support wantClientAuth on NettyAcceptor
> ---
>
> Key: ARTEMIS-1706
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1706
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 2.4.0
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Minor
> Fix For: 2.5.0
>
>
> Currently an acceptor can be configured for 2 way SSL authentication by
> setting needClientAuth to true. It is also useful to be able to set
> wantClientAuth to be true so that two way SSL is requested but isn't required.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1707) [openwire] error on create of queue if another connection creates one of the same name
[
https://issues.apache.org/jira/browse/ARTEMIS-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated ARTEMIS-1707:
--
Description:
When two OpenWire client resources (Producer or Consumer) attempt to create a
Queue destination (generally from two different connections) at the same time
the following exception can be seen:
{noformat}
java.lang.RuntimeException: javax.jms.JMSException:
org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
Binding already exists LocalQueueBinding [address=q2, queue=QueueImpl[name=q2,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
temp=false]@6ca8009b, filter=null, name=q2,
clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
at net.ssorj.quiver.Client.run(QuiverArrowJms.java:126)
at net.ssorj.quiver.QuiverArrowJms.doMain(QuiverArrowJms.java:67)
at net.ssorj.quiver.QuiverArrowJms.main(QuiverArrowJms.java:29)
Caused by: javax.jms.JMSException:
org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
Binding already exists LocalQueueBinding [address=q2, queue=QueueImpl[name=q2,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
temp=false]@6ca8009b, filter=null, name=q2,
clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1399)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1428)
at
org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:2086)
at
org.apache.activemq.ActiveMQMessageProducer.(ActiveMQMessageProducer.java:124)
at
org.apache.activemq.ActiveMQSession.createProducer(ActiveMQSession.java:1117)
at net.ssorj.quiver.Client.sendMessages(QuiverArrowJms.java:136)
at net.ssorj.quiver.Client.run(QuiverArrowJms.java:113)
... 2 more
Caused by: java.lang.Throwable:
org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
Binding already exists LocalQueueBinding [address=q2, queue=QueueImpl[name=q2,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
temp=false]@6ca8009b, filter=null, name=q2,
clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
at
org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addBinding(SimpleAddressManager.java:85)
at
org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:90)
at
org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.addBinding(PostOfficeImpl.java:599)
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:2765)
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:1676)
at
org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:588)
at
org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:668)
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.addDestination(OpenWireConnection.java:768)
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddProducer(OpenWireConnection.java:1086)
at org.apache.activemq.command.ProducerInfo.visit(ProducerInfo.java:108)
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:289)
at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:646)
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultCh
[jira] [Created] (ARTEMIS-1707) [openwire] error on create of queue if another connection creates one of the same name
Timothy Bish created ARTEMIS-1707:
-
Summary: [openwire] error on create of queue if another connection
creates one of the same name
Key: ARTEMIS-1707
URL: https://issues.apache.org/jira/browse/ARTEMIS-1707
Project: ActiveMQ Artemis
Issue Type: Bug
Components: OpenWire
Affects Versions: 2.4.0
Environment: OpenWire protocol head using ActiveMQ JMS client
Reporter: Timothy Bish
Fix For: 2.5.0
When two OpenWire client resources (Producer or Consumer) attempt to create a
Queue destination (generally from two different connection) at the same time
the following exception can be seen:
{noformat}
java.lang.RuntimeException: javax.jms.JMSException:
org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
Binding already exists LocalQueueBinding [address=q2, queue=QueueImpl[name=q2,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
temp=false]@6ca8009b, filter=null, name=q2,
clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
at net.ssorj.quiver.Client.run(QuiverArrowJms.java:126)
at net.ssorj.quiver.QuiverArrowJms.doMain(QuiverArrowJms.java:67)
at net.ssorj.quiver.QuiverArrowJms.main(QuiverArrowJms.java:29)
Caused by: javax.jms.JMSException:
org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
Binding already exists LocalQueueBinding [address=q2, queue=QueueImpl[name=q2,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
temp=false]@6ca8009b, filter=null, name=q2,
clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1399)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1428)
at
org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:2086)
at
org.apache.activemq.ActiveMQMessageProducer.(ActiveMQMessageProducer.java:124)
at
org.apache.activemq.ActiveMQSession.createProducer(ActiveMQSession.java:1117)
at net.ssorj.quiver.Client.sendMessages(QuiverArrowJms.java:136)
at net.ssorj.quiver.Client.run(QuiverArrowJms.java:113)
... 2 more
Caused by: java.lang.Throwable:
org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018:
Binding already exists LocalQueueBinding [address=q2, queue=QueueImpl[name=q2,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2],
temp=false]@6ca8009b, filter=null, name=q2,
clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
at
org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addBinding(SimpleAddressManager.java:85)
at
org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:90)
at
org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.addBinding(PostOfficeImpl.java:599)
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:2765)
at
org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:1676)
at
org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:588)
at
org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:668)
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.addDestination(OpenWireConnection.java:768)
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddProducer(OpenWireConnection.java:1086)
at org.apache.activemq.command.ProducerInfo.visit(ProducerInfo.java:108)
at
org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:289)
at
org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:646)
at
org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChan
[jira] [Commented] (ARTEMIS-1700) Server stopped responding and killed itself while exiting paging state
[ https://issues.apache.org/jira/browse/ARTEMIS-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378932#comment-16378932 ] ASF GitHub Bot commented on ARTEMIS-1700: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1899 @shoukunhuai see #1904 > Server stopped responding and killed itself while exiting paging state > -- > > Key: ARTEMIS-1700 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1700 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.4.0 >Reporter: Qihong Xu >Priority: Major > Attachments: artemis.log > > > We are currently experiencing this error while running stress test on artemis. > > Basic configuration: > 1 broker ,1 topic, pub-sub mode. > Journal type = MAPPED. > Threadpool max size = 60. > > In order to test the throughput of artemis we use 300 producers and 300 > consumers. However we found that sometimes when artemis exit paging state, it > will stop responding and kill itself. This situatuion happened on some > specific servers. > > Details can be found in attached dump file. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1700) Server stopped responding and killed itself while exiting paging state
[ https://issues.apache.org/jira/browse/ARTEMIS-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378931#comment-16378931 ] ASF GitHub Bot commented on ARTEMIS-1700: - GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/1904 ARTEMIS-1700 Using IOExecutors for more IO tasks You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis deadlock Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/1904.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 #1904 > Server stopped responding and killed itself while exiting paging state > -- > > Key: ARTEMIS-1700 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1700 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.4.0 >Reporter: Qihong Xu >Priority: Major > Attachments: artemis.log > > > We are currently experiencing this error while running stress test on artemis. > > Basic configuration: > 1 broker ,1 topic, pub-sub mode. > Journal type = MAPPED. > Threadpool max size = 60. > > In order to test the throughput of artemis we use 300 producers and 300 > consumers. However we found that sometimes when artemis exit paging state, it > will stop responding and kill itself. This situatuion happened on some > specific servers. > > Details can be found in attached dump file. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-6905) Resource Adapter clientId ActivationConfigProperty does conform to API document
Darren Merritt created AMQ-6905: --- Summary: Resource Adapter clientId ActivationConfigProperty does conform to API document Key: AMQ-6905 URL: https://issues.apache.org/jira/browse/AMQ-6905 Project: ActiveMQ Issue Type: Bug Components: RAR Affects Versions: 5.15.3 Reporter: Darren Merritt According to the following page [http://activemq.apache.org/activation-spec-properties.html] The clientId default is set by the resource adapter. This is not the case in the code. When defining the MDB to be Durable via subscriptionDurability, if the clientId is not configured an validation error is thrown stating "clientId must be set since durable subscription was requested". Looking at the code, if the documentation is correct, the ActiveMQActivationSpec validation method should no longer validate the clientId. The ActiveMQConnection makeConnection should change String clientId = activationSpec.getClientId(); to String clientId = defaultValue(activationSpec.getClientId(), getInfo().getClientid()); -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1700) Server stopped responding and killed itself while exiting paging state
[ https://issues.apache.org/jira/browse/ARTEMIS-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378700#comment-16378700 ] ASF GitHub Bot commented on ARTEMIS-1700: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1899 You're right.. Man!!! you're good! :) I will send another PR! > Server stopped responding and killed itself while exiting paging state > -- > > Key: ARTEMIS-1700 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1700 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.4.0 >Reporter: Qihong Xu >Priority: Major > Attachments: artemis.log > > > We are currently experiencing this error while running stress test on artemis. > > Basic configuration: > 1 broker ,1 topic, pub-sub mode. > Journal type = MAPPED. > Threadpool max size = 60. > > In order to test the throughput of artemis we use 300 producers and 300 > consumers. However we found that sometimes when artemis exit paging state, it > will stop responding and kill itself. This situatuion happened on some > specific servers. > > Details can be found in attached dump file. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1706) Support wantClientAuth on NettyAcceptor
[ https://issues.apache.org/jira/browse/ARTEMIS-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378699#comment-16378699 ] ASF GitHub Bot commented on ARTEMIS-1706: - GitHub user cshannon opened a pull request: https://github.com/apache/activemq-artemis/pull/1903 ARTEMIS-1706 - Add support for wantClientAuth Support setting wantClientAuth on a netty acceptor You can merge this pull request into a Git repository by running: $ git pull https://github.com/cshannon/activemq-artemis ARTEMIS-1706 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/1903.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 #1903 commit d52397a8db814dc7d470c2d4bf049c680713d969 Author: Christopher L. Shannon (cshannon) Date: 2018-02-27T14:47:36Z ARTEMIS-1706 - Add support for wantClientAuth Support setting wantClientAuth on a netty acceptor > Support wantClientAuth on NettyAcceptor > --- > > Key: ARTEMIS-1706 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1706 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 2.5.0 > > > Currently an acceptor can be configured for 2 way SSL authentication by > setting needClientAuth to true. It is also useful to be able to set > wantClientAuth to be true so that two way SSL is requested but isn't required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1706) Support wantClientAuth on NettyAcceptor
Christopher L. Shannon created ARTEMIS-1706: --- Summary: Support wantClientAuth on NettyAcceptor Key: ARTEMIS-1706 URL: https://issues.apache.org/jira/browse/ARTEMIS-1706 Project: ActiveMQ Artemis Issue Type: New Feature Components: Broker Affects Versions: 2.4.0 Reporter: Christopher L. Shannon Assignee: Christopher L. Shannon Fix For: 2.5.0 Currently an acceptor can be configured for 2 way SSL authentication by setting needClientAuth to true. It is also useful to be able to set wantClientAuth to be true so that two way SSL is requested but isn't required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1706) Support wantClientAuth on NettyAcceptor
[ https://issues.apache.org/jira/browse/ARTEMIS-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated ARTEMIS-1706: Issue Type: Improvement (was: New Feature) > Support wantClientAuth on NettyAcceptor > --- > > Key: ARTEMIS-1706 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1706 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.4.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 2.5.0 > > > Currently an acceptor can be configured for 2 way SSL authentication by > setting needClientAuth to true. It is also useful to be able to set > wantClientAuth to be true so that two way SSL is requested but isn't required. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1703) Restrict directory listings of Hawtio within the web server configuration
[ https://issues.apache.org/jira/browse/ARTEMIS-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378516#comment-16378516 ] Stanislav Knot commented on ARTEMIS-1703: - I did a typo in PR title. There is link to github: https://github.com/apache/activemq-artemis/pull/1898 > Restrict directory listings of Hawtio within the web server configuration > - > > Key: ARTEMIS-1703 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1703 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Stanislav Knot >Assignee: Stanislav Knot >Priority: Major > > The web console allows access to directory listings which should be > restricted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1656) OpenWire scalability improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378513#comment-16378513 ] ASF GitHub Bot commented on ARTEMIS-1656: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/1849 > OpenWire scalability improvements > - > > Key: ARTEMIS-1656 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1656 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > > OpenWire is using the synchronized OpenWireFormat instance belonging to > OpenWireProtocolManager: it won't allow to scale with the number of > connections. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1656) OpenWire scalability improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378512#comment-16378512 ] ASF subversion and git services commented on ARTEMIS-1656: -- Commit b5fa5ed3b743dabf1e40cfcaa97f1ca05cdbdef5 in activemq-artemis's branch refs/heads/master from [~nigro@gmail.com] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=b5fa5ed ] ARTEMIS-1656 OpenWire scalability improvements OpenWireFormat instances are shared between OpenWire connections/sessions/consumers, preventing the clients to scale due to the synchronized marshal/unmarshal on it. It includes: - direct transport buffer pooling - groupId SimpleString pooling - clientId SimpleString pooling - reduced ActiveMQDestination[] and AtomicLong allocations on AMQSession:send - reduced ActiveMQDestination allocations - refactored shouldBlockProducer path of AMQPSession::send to reduce method size - exclusive OpenWireFormat per session and connection (in/out) to avoid contention - refactored trace log to favour inlining - changed lastSent volatile set into lazy set to avoid full barrier cost on x86 - stateless OpenWireMessageConverter - send's lock removal thanks to thread-safe NettyConnection > OpenWire scalability improvements > - > > Key: ARTEMIS-1656 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1656 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > > OpenWire is using the synchronized OpenWireFormat instance belonging to > OpenWireProtocolManager: it won't allow to scale with the number of > connections. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1656) OpenWire scalability improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378508#comment-16378508 ] ASF GitHub Bot commented on ARTEMIS-1656: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1849 @franz1981 @michaelandrepearce I think it's good and am going to merge it. > OpenWire scalability improvements > - > > Key: ARTEMIS-1656 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1656 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > > OpenWire is using the synchronized OpenWireFormat instance belonging to > OpenWireProtocolManager: it won't allow to scale with the number of > connections. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1676) Allow users to override JAVA_ARGS via environment variables
[ https://issues.apache.org/jira/browse/ARTEMIS-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378491#comment-16378491 ] ASF GitHub Bot commented on ARTEMIS-1676: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1862 @mtaylor can you update the Windows artemis.profile.cmd, I can test it on Windows. > Allow users to override JAVA_ARGS via environment variables > --- > > Key: ARTEMIS-1676 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1676 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Martyn Taylor >Priority: Major > > We currently require users to update the artemis.profile file to change > JAVA_ARGS options. However, it's often useful to be able to override > certain properties via environment variables. Typical example is when > running in a cloud environment, where customisation is often injected via > environment variables. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1661) Enable splitting of broker.xml into multiple files
[ https://issues.apache.org/jira/browse/ARTEMIS-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378482#comment-16378482 ] ASF subversion and git services commented on ARTEMIS-1661: -- Commit 9d1c59cdff5c0084964611147a0433a165c8d989 in activemq-artemis's branch refs/heads/master from [~michael.andre.pearce] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=9d1c59c ] ARTEMIS-1661 Support splitting of broker.xml Support XML standard XInclude thus allowing splitting of the broker.xml Added test cases with split out config using include. > Enable splitting of broker.xml into multiple files > -- > > Key: ARTEMIS-1661 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1661 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Adi Rubin >Priority: Minor > > Hi, > Broker.xml contains both server configuration (connectors, cluster config > etc) and addresses/queues. It would be useful to be able to move the > element to a separate file(s). An example use case would be > generation of addresses using a script. > Ideally, this should apply to all configuration elements in broker.xml. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1661) Enable splitting of broker.xml into multiple files
[ https://issues.apache.org/jira/browse/ARTEMIS-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378483#comment-16378483 ] ASF GitHub Bot commented on ARTEMIS-1661: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/1896 > Enable splitting of broker.xml into multiple files > -- > > Key: ARTEMIS-1661 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1661 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Adi Rubin >Priority: Minor > > Hi, > Broker.xml contains both server configuration (connectors, cluster config > etc) and addresses/queues. It would be useful to be able to move the > element to a separate file(s). An example use case would be > generation of addresses using a script. > Ideally, this should apply to all configuration elements in broker.xml. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1661) Enable splitting of broker.xml into multiple files
[ https://issues.apache.org/jira/browse/ARTEMIS-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378480#comment-16378480 ] ASF GitHub Bot commented on ARTEMIS-1661: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1896 @adirubin good point. I'm going to merge this and improve it in a separate commit. > Enable splitting of broker.xml into multiple files > -- > > Key: ARTEMIS-1661 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1661 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Adi Rubin >Priority: Minor > > Hi, > Broker.xml contains both server configuration (connectors, cluster config > etc) and addresses/queues. It would be useful to be able to move the > element to a separate file(s). An example use case would be > generation of addresses using a script. > Ideally, this should apply to all configuration elements in broker.xml. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1698) Support "instance" web deployments
[
https://issues.apache.org/jira/browse/ARTEMIS-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378473#comment-16378473
]
ASF GitHub Bot commented on ARTEMIS-1698:
-
Github user gaohoward commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1889#discussion_r170900438
--- Diff:
artemis-web/src/main/java/org/apache/activemq/artemis/component/WebServerComponent.java
---
@@ -95,34 +95,51 @@ public void configure(ComponentDTO config, String
artemisInstance, String artemi
handlers = new HandlerList();
- Path warDir = Paths.get(artemisHome != null ? artemisHome :
".").resolve(webServerConfig.path).toAbsolutePath();
+ Path homeWarDir = Paths.get(artemisHome != null ? artemisHome :
".").resolve(webServerConfig.path).toAbsolutePath();
+ Path instanceWarDir = Paths.get(artemisInstance != null ?
artemisInstance : ".").resolve(webServerConfig.path).toAbsolutePath();
if (webServerConfig.apps != null && webServerConfig.apps.size() > 0)
{
webContexts = new ArrayList<>();
for (AppDTO app : webServerConfig.apps) {
-WebAppContext webContext = deployWar(app.url, app.war, warDir);
+Path dirToUse = homeWarDir;
+if (new File(instanceWarDir.toFile().toString() +
File.separator + app.war).exists()) {
+ dirToUse = instanceWarDir;
+}
+WebAppContext webContext = deployWar(app.url, app.war,
dirToUse);
webContexts.add(webContext);
if (app.war.startsWith("console")) {
consoleUrl = webServerConfig.bind + "/" + app.url;
}
}
}
- ResourceHandler resourceHandler = new ResourceHandler();
- resourceHandler.setResourceBase(warDir.toString());
- resourceHandler.setDirectoriesListed(false);
- resourceHandler.setWelcomeFiles(new String[]{"index.html"});
+ ResourceHandler homeResourceHandler = new ResourceHandler();
+ homeResourceHandler.setResourceBase(homeWarDir.toString());
+ homeResourceHandler.setDirectoriesListed(false);
+ homeResourceHandler.setWelcomeFiles(new String[]{"index.html"});
+
+ ContextHandler homeContext = new ContextHandler();
+ homeContext.setContextPath("/");
+ homeContext.setResourceBase(homeWarDir.toString());
+ homeContext.setHandler(homeResourceHandler);
+
homeContext.setInitParameter("org.eclipse.jetty.servlet.Default.dirAllowed",
"false");
+
+ ResourceHandler instanceResourceHandler = new ResourceHandler();
+ instanceResourceHandler.setResourceBase(instanceWarDir.toString());
+ instanceResourceHandler.setDirectoriesListed(false);
+ instanceResourceHandler.setWelcomeFiles(new String[]{"index.html"});
+
+ ContextHandler instanceContext = new ContextHandler();
+ instanceContext.setContextPath("/");
+ instanceContext.setResourceBase(instanceWarDir.toString());
+ instanceContext.setHandler(instanceResourceHandler);
+
homeContext.setInitParameter("org.eclipse.jetty.servlet.Default.dirAllowed",
"false");
--- End diff --
@jbertram It looks like setting two root ("/") resource handlers can cause
confusion. According to my test when 'index.html' appears in both {home}/web
and {instance}/web, it picks up the one in {home}/web.
> Support "instance" web deployments
> --
>
> Key: ARTEMIS-1698
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1698
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> Currently any web application deployment to the embedded Jetty instance must
> be done via the "web" directory of the Artemis "home" installation. This
> includes things like the web console or REST interface. We should support
> deployments in the "web" directory of the Artemis "instance" as well so
> instances can have better control over what web applications they deploy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1661) Enable splitting of broker.xml into multiple files
[ https://issues.apache.org/jira/browse/ARTEMIS-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378450#comment-16378450 ] ASF GitHub Bot commented on ARTEMIS-1661: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/1896 @gaohoward Updated docs 👍 > Enable splitting of broker.xml into multiple files > -- > > Key: ARTEMIS-1661 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1661 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Adi Rubin >Priority: Minor > > Hi, > Broker.xml contains both server configuration (connectors, cluster config > etc) and addresses/queues. It would be useful to be able to move the > element to a separate file(s). An example use case would be > generation of addresses using a script. > Ideally, this should apply to all configuration elements in broker.xml. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1661) Enable splitting of broker.xml into multiple files
[ https://issues.apache.org/jira/browse/ARTEMIS-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378444#comment-16378444 ] ASF GitHub Bot commented on ARTEMIS-1661: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/1896 @adirubin thats correct, you'll need to "touch" the broker.xml file still, this is very similar to the support for config modularity such as log4j e.g. there also you need to "touch" the log4j.xml still. > Enable splitting of broker.xml into multiple files > -- > > Key: ARTEMIS-1661 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1661 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Adi Rubin >Priority: Minor > > Hi, > Broker.xml contains both server configuration (connectors, cluster config > etc) and addresses/queues. It would be useful to be able to move the > element to a separate file(s). An example use case would be > generation of addresses using a script. > Ideally, this should apply to all configuration elements in broker.xml. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1603) Browsing in hawtio console under JMX tab is broken
[ https://issues.apache.org/jira/browse/ARTEMIS-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378434#comment-16378434 ] ASF GitHub Bot commented on ARTEMIS-1603: - Github user stanlyDoge commented on the issue: https://github.com/apache/activemq-artemis/pull/1837 AFAIK there is some effort to create some Selenium tests. I am not sure when it could get into upstream. > Browsing in hawtio console under JMX tab is broken > --- > > Key: ARTEMIS-1603 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1603 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Stanislav Knot >Assignee: Stanislav Knot >Priority: Minor > > 1. create & start broker > 2. go to JMX tab of hawtio console > 3. [create] and choose queue > 4. select (for example) addresses tab > 5. you are redirected to attributes (before that, you are redirected to > Artemis/addresses) > 6. select browse > 7. back to step 4 - now works fine > It goes to Artemis tab and back to JMX attributes. Table data are fetched > correctly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1661) Enable splitting of broker.xml into multiple files
[ https://issues.apache.org/jira/browse/ARTEMIS-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378398#comment-16378398 ] ASF GitHub Bot commented on ARTEMIS-1661: - Github user adirubin commented on the issue: https://github.com/apache/activemq-artemis/pull/1896 Hi michaelandrepearce, thanks! If I'm not mistaken, the server won't monitor the x-included files for changes, which could be a problem. > Enable splitting of broker.xml into multiple files > -- > > Key: ARTEMIS-1661 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1661 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Reporter: Adi Rubin >Priority: Minor > > Hi, > Broker.xml contains both server configuration (connectors, cluster config > etc) and addresses/queues. It would be useful to be able to move the > element to a separate file(s). An example use case would be > generation of addresses using a script. > Ideally, this should apply to all configuration elements in broker.xml. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQCPP-625) Inactivity mointor core dump
[ https://issues.apache.org/jira/browse/AMQCPP-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378343#comment-16378343 ] Abhijit commented on AMQCPP-625: Using amq-cpp lib version: 5.13.4 > Inactivity mointor core dump > - > > Key: AMQCPP-625 > URL: https://issues.apache.org/jira/browse/AMQCPP-625 > Project: ActiveMQ C++ Client > Issue Type: Bug > Components: Decaf, Openwire >Reporter: Abhijit >Assignee: Timothy Bish >Priority: Major > > Broker Configuration: > > uri="tcp://0.0.0.0:61616?maximumConnections=1000&wireFormat.maxFrameSize=104857600&transport.useInactivityMonitor=false"/> > Client configuration: > --- > failover://(tcp://192.168.114.105:61616,tcp://192.168.114.105:61616)?randomize=false&wireFormat=openwire&transport.useInactivityMonitor=false > > Application cores/crashes and generates core file, even when in idle state. > Below is the backtrace - Not sure if this is related to inactivity monitor > (gdb) bt > #0 0x7f2dd9bff989 in raise () from /lib64/libc.so.6 > #1 0x7f2dd9c01098 in abort () from /lib64/libc.so.6 > #2 0x7f2dda5039d5 in __gnu_cxx::__verbose_terminate_handler() () from > /lib64/libstdc++.so.6 > #3 0x7f2dda501946 in ?? () from /lib64/libstdc++.so.6 > #4 0x7f2dda501973 in std::terminate() () from /lib64/libstdc++.so.6 > #5 0x7f2dda5024df in __cxa_pure_virtual () from /lib64/libstdc++.so.6 > #6 0x7f2ddc404baa in decaf::util::concurrent::Lock::~Lock > (this=0x7f2d637fdbf0, __in_chrg=) at > decaf/util/concurrent/Lock.cpp:46 > #7 0x7f2ddc221e80 in activemq::threads::CompositeTaskRunner::wakeup > (this=) at activemq/threads/CompositeTaskRunner.cpp:154 > #8 0x7f2ddc282c95 in > activemq::transport::inactivity::InactivityMonitor::readCheck > (this=0x7f2d70003a50) > at activemq/transport/inactivity/InactivityMonitor.cpp:400 > #9 0x7f2ddc3ffe5d in decaf::util::TimerImpl::run (this=0x7f2d70002160) at > decaf/util/Timer.cpp:156 > #10 0x7f2ddc37b622 in (anonymous namespace)::runCallback > (arg=0x7f2d70002670) at decaf/internal/util/concurrent/Threading.cpp:268 > #11 0x7f2ddc37beec in (anonymous namespace)::threadEntryMethod > (arg=0x7f2d70002670) at decaf/internal/util/concurrent/Threading.cpp:256 > #12 0x7f2dda9b4df3 in start_thread () from /lib64/libpthread.so.0 > #13 0x7f2dd9cc03dd in clone () from /lib64/libc.so.6 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQCPP-625) Inactivity mointor core dump
Abhijit created AMQCPP-625: -- Summary: Inactivity mointor core dump Key: AMQCPP-625 URL: https://issues.apache.org/jira/browse/AMQCPP-625 Project: ActiveMQ C++ Client Issue Type: Bug Components: Decaf, Openwire Reporter: Abhijit Assignee: Timothy Bish Broker Configuration: Client configuration: --- failover://(tcp://192.168.114.105:61616,tcp://192.168.114.105:61616)?randomize=false&wireFormat=openwire&transport.useInactivityMonitor=false Application cores/crashes and generates core file, even when in idle state. Below is the backtrace - Not sure if this is related to inactivity monitor (gdb) bt #0 0x7f2dd9bff989 in raise () from /lib64/libc.so.6 #1 0x7f2dd9c01098 in abort () from /lib64/libc.so.6 #2 0x7f2dda5039d5 in __gnu_cxx::__verbose_terminate_handler() () from /lib64/libstdc++.so.6 #3 0x7f2dda501946 in ?? () from /lib64/libstdc++.so.6 #4 0x7f2dda501973 in std::terminate() () from /lib64/libstdc++.so.6 #5 0x7f2dda5024df in __cxa_pure_virtual () from /lib64/libstdc++.so.6 #6 0x7f2ddc404baa in decaf::util::concurrent::Lock::~Lock (this=0x7f2d637fdbf0, __in_chrg=) at decaf/util/concurrent/Lock.cpp:46 #7 0x7f2ddc221e80 in activemq::threads::CompositeTaskRunner::wakeup (this=) at activemq/threads/CompositeTaskRunner.cpp:154 #8 0x7f2ddc282c95 in activemq::transport::inactivity::InactivityMonitor::readCheck (this=0x7f2d70003a50) at activemq/transport/inactivity/InactivityMonitor.cpp:400 #9 0x7f2ddc3ffe5d in decaf::util::TimerImpl::run (this=0x7f2d70002160) at decaf/util/Timer.cpp:156 #10 0x7f2ddc37b622 in (anonymous namespace)::runCallback (arg=0x7f2d70002670) at decaf/internal/util/concurrent/Threading.cpp:268 #11 0x7f2ddc37beec in (anonymous namespace)::threadEntryMethod (arg=0x7f2d70002670) at decaf/internal/util/concurrent/Threading.cpp:256 #12 0x7f2dda9b4df3 in start_thread () from /lib64/libpthread.so.0 #13 0x7f2dd9cc03dd in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1637) artemis data exp does not work with JDBC store
[
https://issues.apache.org/jira/browse/ARTEMIS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378296#comment-16378296
]
Jiri Daněk commented on ARTEMIS-1637:
-
I've reported it before ARTEMIS-1613 was merged. I did not know ARTEMIS-1613
had been in the works.
> artemis data exp does not work with JDBC store
> --
>
> Key: ARTEMIS-1637
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1637
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Environment: apache-artemis-2.5.0-20180111.113938-84-bin
> postgres (PostgreSQL) 10.1
>Reporter: Jiri Daněk
>Priority: Major
>
> Prepare database
> {noformat}
> initdb .
> pg_ctl -D . -l logfile start
> createdb test
> {noformat}
> Configure broker (changes from defaul)
> {noformat}
> diff --git a/broker.xml b/broker.xml
> index ea55343..ea5131b 100644
> --- a/broker.xml
> +++ b/broker.xml
> @@ -29,45 +29,16 @@ under the License.
>
>true
>
> -
> - NIO
> -
> - ./data/paging
> -
> - ./data/bindings
> -
> - ./data/journal
> -
> -
> ./data/large-messages
> -
> - true
> -
> - 2
> -
> - -1
> -
> - 10M
> -
> -
> - 2864000
> -
> -
> -
> - 1
> +
> +
> +
>
> + BINDINGS_TABLE
> + MESSAGE_TABLE
> + MESSAGE_T
> +
> LARGE_MESSAGES_TABLE
> +
> org.postgresql.Driver
> +
> +
>
[jira] [Commented] (ARTEMIS-1702) ConcurrentLongHashMap and ConcurrentLongHashSet should avoid volatile set cost on put/remove
[ https://issues.apache.org/jira/browse/ARTEMIS-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378248#comment-16378248 ] ASF GitHub Bot commented on ARTEMIS-1702: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/1895 @michaelandrepearce Yes, tested yesterday: exactly the same :+1: (and for free :P) > ConcurrentLongHashMap and ConcurrentLongHashSet should avoid volatile set > cost on put/remove > > > Key: ARTEMIS-1702 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1702 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.5.0 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.5.0 > > > ConcurrentLongHashSet/HashMap are making use of unecessary volatile store of > size/capacity for modifier methods. > The current JVM implementation of volatile store for multicore x86 is making > use of a StoreLoad barrier for this operation: the most expensive one. > These volatile stores could be replaced by plain stores/lazySet ones with no > effects on the correctness of those methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1656) OpenWire scalability improvements
[ https://issues.apache.org/jira/browse/ARTEMIS-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378246#comment-16378246 ] ASF GitHub Bot commented on ARTEMIS-1656: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/1849 @michaelandrepearce Yep, it has passed the same tests as master with no regressions, hence it can be merged :+1: > OpenWire scalability improvements > - > > Key: ARTEMIS-1656 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1656 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > > OpenWire is using the synchronized OpenWireFormat instance belonging to > OpenWireProtocolManager: it won't allow to scale with the number of > connections. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
