The failback process needs to be deterministic rather than relying on various
incarnations of Thread.sleep() at crucial points. Important aspects of this
change include:
1) Make the initial replication synchronization process block at the very
last step and wait for a response from the replica to ensure the replica has
as the necessary data. This is a critical piece of knowledge during the
failback process because it allows the soon-to-become-backup server to know
for sure when it can shut itself down and allow the soon-to-become-live
server to take over. Also, introduce a new configuration element called
"initial-replication-sync-timeout" to conrol how long this blocking will occur.
2) Set the state of the server as 'LIVE' only after the server is fully
started. This is necessary because once the soon-to-be-backup server shuts
down it needs to know that the soon-to-be-live server has started fully before
it restarts itself as the new backup. If the soon-to-be-backup server restarts
before the soon-to-be-live is fully started then it won't actually become a
backup server but instead will become a live server which will break the
failback process.
3) Wait to receive the announcement of a backup server before failing-back.
Netty 4.x uses pooled buffers. These buffers can run out of memory when
transferring large amounts of data over connection. This was causing an
OutOfMemory exception to be thrown on the CoreBridge when tranferring
large messages. Netty provides a callback handler to notify listeners
when a Connection is writable. This patch adds the ability to register
connection writable listeners to the Netty connection and registers the
relevant callback from the Bridge to avoid writing when the buffers are
full.
It is possible for the closure of one resource to potentially impact
another since they are now sharing the same ServerLocator instance.
Keep track of references to avoid this.
In one situation I have seen a failrue on ProducerFlowControl to break everything else from here
This change will both avoid the failure and change the report of leaked threads so we can find them easily on the system.out when it happens (for future debugging)
-Using core api to inspect queue status
-Catch command visit() exceptions in order to
pass it back to client.
-Correct destination add/remove handlings
Inbound sessions are always created from the same ActiveMQConnectionFactory
which means the load-balancing policy is applied to them in the expected
manner. However, outbound sessions are created from independent, unique
ActiveMQConnectionFactory instances which means that the load-balancing
doesn't follow the expected pattern.
This commit changes this behavior by caching each unique
ActiveMQConnectionFactory instance and using it for both inbound and outbound
sessions potentially. This ensures the sessions are load-balanced as
expected.
Currently a cluster bridge will continue to attempt to reconnect to
a node that sends it a DISCONNECT until its reconnect-attempts is
exhausted. A DISCONNECT message indicates that the node is not coming
back so no reconnect attempt should be made and the bridge should be
stopped, the bindings should be cleaned up, etc.
The change to this test exposes this problem.
this is just calling Idea format on all the files using the new style
I am separating manual changes from automatic changes in case I have to repeat the manual changes again
https://issues.apache.org/jira/browse/ARTEMIS-163
On this pass I'm just converting the native layer to a simpler one.
It wasn't very easy to change the alignment at the current framework,
so I did some refactoring simplifying the native layer
The volume of the nubmer of changes here is because:
- The API is changed, we now don't close the libaio queue between files
- The native layer won't use malloc as much as it used to, saving some CPU and memory defragmentation
- I organized the code around nio and libaio
-- added addConnector() method so new connector can be created for tests
-- fix zero-byte key store files that cause test failures
-- fix a invm issue in test
The current Security Manager implementation was returning the username
instead of the default password when validating the default user.
This patch returns the correct value and cleans up the validate method.
https://issues.apache.org/jira/browse/ARTEMIS-138
The list method should return an empty list in case of non existent folders,
So this would unveil whatever is the cause for non existent folders at the next level where it's happening
https://issues.apache.org/jira/browse/ARTEMIS-136
From what I researched from implementers of XA TM if you throw ERR over communication errors the transaction manager will create
an heuristic transaction to be manually dealt with.
Other XA Implementations (such as Oracle JDBC) are return FAIL over communication failures during any XA operation.
https://issues.apache.org/jira/browse/ARTEMIS-135
This is importing a recent fix from the journal on the old version.
If a crash happened between the create file and the fill of the file the
file wouldn't be loaded and the server wouldn't start until you removed the offending file
To reproduce this commit, apply a replace regex rule using:
search regex: /\*\*\n \* Licensed
replace: /\*\n \* Licensed
These files had to be changed manually:
artemis-selector/src/main/javacc/HyphenatedParser.jj
artemis-selector/src/main/javacc/StrictParser.jj
artemis-website/src/main/resources/styles/impact/css/pygmentize.css
artemis-website/src/main/resources/styles/impact/css/site.css
We had a few reported small issues on the codebase from the recent introduced google error prone.
This should eliminate any issues, and I am making sure these won't happen again
If standalone backup server with shared has defined scale-down policy
but it's disabled then backup does not activate. Problem is that
server is checking only whether scale down is defined but if it's
enabled. This causes that server.stop() is called and backup does
not activate.
Lots of work on the test-suite in this commit including:
- Rename ServiceTestBase to ActiveMQTestBase
- Make AddressSettings fluent
- Remove unnecessary tearDown() implementations
- Use ActiveMQTestBase.create*Locator() instead of
ActiveMQClient.createServerLocator*(..)
- Use fluent ServerLocator methods
- Make sure all ActiveMQServers.newActiveMQServer invocations
are surrounded with addServer() where appropriate
- Create a few example tests to be references from hacking-guide
- Update hacking-guide with more info on writing tests
- Refactor config creation methods in ActiveMQTestBase
This has bothered me for awhile, but writing the hacking guide has
given me an opportunity to refactor some of our test-suite to be
simpler, more consistent, and easier to understand. This is
important if we want users to provide well-written tests. Our
test-suite is an important part of the code-base and it should be
easy to write good tests.
Basically I just consolidated CoreUnitTestCase, UnitTestCase, and
ServiceTestBase into a single class named ServiceTestBase. I also
simplified some of the configuration creation methods to reduce
duplicated code.
This commit is a simple mv of the files.. We required two commits to preserve history,
one to git mv, one for the actual changes...
otherwise history would be lost
Based on the Apache ActiveMQ community vote this project is being
renamed "Artemis."
When sending a large message that exceeds the size of
Integer.MAX_VALUE, the bridge will get negative chunk size during
fowarding. And the resend cache is not limited so there is a
potential that it may get OutOfMemory exception.
this is basically addressing a performance issue on OpenWire, setting the auto-create to the PostOffice
after not being able to route
The core protocol stays the same in regard to the auto-create since the exceptions are happening after the queueQuery
Sometimes /tmp doesn't support ext4 (tmpfs) and there's always a risk of leaving unnatended files in cases of crashed.
This is in alignment with how other tests run at apache
If a Transaction wasn't created, the case for duplciate Detection would cancel a transaction that never happened
and it would get a NPE instead of a TX Exception.
It wasn't a big deal as the client got an exception anyways and the users were able to cancel in that case
but the message sent was a string containing just "Null".
this will fix it with a proper handling
https://issues.apache.org/jira/browse/ACTIVEMQ6-95
The message.copy is broken when you set persistence=false, and the bridge will use that method before forwarding the message
this commit is fixing NullStorageLargeServerMessage.copy and adding the proper testcase to validate the fix
https://issues.apache.org/jira/browse/ACTIVEMQ6-89
I have done a lot of refactoring on this. So we can a different version of the interceptor for each protocol based on a base class now.
Just an abstract class over Stomp would be a bit hacky... this is a better approach.
- Bumped up version to 2.0.0.Alpha
- Client bundle changes to be copmatible with 2.0.0
- Fixing bundle / Logging classes for missing format (it was an issue with the previous one already)
- Fixed up dependencies to avoid transient downloads
- removing unused methods
- moving JMSXdeliveryCountTest to /extra-tests
- A few transactions methods that were not being used and creating issues to the release
due to an old dependency to the TM
This closes#173
Returns an error to the client causing InvalidDestinationException to be
thrown when an ActiveMQ 5.x client attempts to create a producer with a
destination that does not exist. (Over OpenWire Protocol).
This was causing issues with javadoc
utils is also a package on activemq-server. ActiveMQUtilLogger is using a super class that was not part of the
source path on the javadoc plugin what caused it to exception and interrupt building
Fixing the classpath so some tests would find the LogManager configured
Fixing the dependency on the AssertionLoggerHandler so all the tests could also see it without further errors
My previous commit broke the location of the ServiceUtil / TransactionManagerLocator
This commit is setting a new DummyTM on the integration-tests-suite and the proper TM Locator on the extra-tests
With these changes the testsuite is not using any LGPL code by default. Anything woud go through extra-tests
These following changes were made on this commit (in summary):
- renamed byteman-tests as extra-tests
- added extra-tests on a new profile called extra-tests
- added all the other tests back to the tests profile
- removed concurrent-tests and moved them all to timing-tests
- removed old tests that were ignored for a long time and were stale
When a live and backup server are both started at or near the same moment
there is a small window where the live server's acceptors have been
started but the server's state != STARTED. During this window if the
backup sends its announcement the announcement will fail and the backup
will shutdown. This fix closes this small window by only starting the
acceptors until the server is fully started.
Also removing the word Netty from the starting acceptor and its version
I don't think it's necessary to mention Netty at the console or its version.
That's internal implementation detail at this point
In some cases the ID Generator will be called after the JournalStorage was stopped.
AS a result you could have cases where the ID generator is called and the journal storage is stopped.
Also I added some check to IDs and added some code to cleanup old IDS on the BatchIDManager
A bug was recently discovered on a legacy HornetQ branch. ActiveMQ 6
doesn't suffer from the same problem, but the test is still valuable.
The HornetQ issue is described on
https://bugzilla.redhat.com/show_bug.cgi?id=1193085.
Remove the reference to the JBoss Maven repo, and make all the necessary
adjustments on the child-projects. It turns out we don't even need the
security dependencies in the tests.
Implements a new feature for the broker whereby it may automatically
create and delete queues which are not explicitly defined through
the management API or file-based configuration when a client sends a
message to or receives from a queue via the AMQP protocol. Note,
the destination has to be named like "jms.queue.*" to be auto-
created. The queue may subsequently be deleted when it no longer has
any messages and consumers. Auto-creation and auto-deletion can both
be turned on/off via address-setting.
https://issues.apache.org/jira/browse/ACTIVEMQ6-7
Connection Factory is now externalizable and is now serialized as a string that represents a URI. There are schemas for every possible type for connection factory and server locator.
The client JNDI representation of factories has also been changed to be consistent with this.
This test started to fail after performance improvements from ACTIVEMQ6-78
After some investigation it turned out that this test was racing with the client
crashing even before the queue was created or sending a non persistent message
asynchronously while the client crashed before the server received the message.
I've also decreased some of the times on pings so the test could run a bit faster
https://issues.apache.org/jira/browse/ACTIVEMQ6-78 performance work
There are two aspects of this work. First avoid asynchronous packets and avoid
context switch over the executors. Packet had a method to make certain packets such
as commit to use a different executor. Since it's NIO everything is done at the Netty thread now.
The second aspect was to make sure we use the proper buffering
https://issues.apache.org/jira/browse/ACTIVEMQ6-78
This commit is just adding tests I used to debug the blocked calls issue
There are some profiling parameters you can use that I added as a comment to the pom
The reason this is a separate commit is that it would be easier to validate the results of optimizations while
checking after and before any changes
Implements a new feature for the broker whereby it may automatically
create and delete queues which are not explicitly defined through
the management API or file-based configuration when a client sends a
message to or consumes from a queue via the STOMP protocol. Note,
the destination has to be named like "jms.queue.*" to be auto-
created. The queue may subsequently be deleted when it no longer has
any messages and consumers. Auto-creation and auto-deletion can both
be turned on/off via address-setting.