Ive renamed the current isSameHost method to isSameparams as thats what it checked and added a new method for isSameHost that checks the appropriate params for the connector. Ive changed ClientSessionFactoryImp to use this to correct the behaviour.
https://issues.apache.org/jira/browse/ARTEMIS-292
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.
A transaction manager is only required on the JMSBridge when the QoS
level is set to ONCE_AND_ONCE_ONLY. Previous to the this patch it was
also checking for a TM on the AT_MOST_ONCE QoS level. This patch also
ensures that the TM is set to null after each test run.
These tests were not as broken as on 2.3.x from the old hornetq branch where this fix originated.
However I will play safe here as I believe the race could be after the exception is raised and before the counter was added
(on ActiveMQMessageHandlerTest)
Implements a feature whereby the broker will not shutdown while there are
clients connected. A timeout can be specified so that even if there are
clients connected the broker will still shutdown after a certain time.
This patch moves test dependencies into out of the main pom and into the
tests module pom. This will make managing 3rd party category X
dependencies much easier going forward. In addition each dependency
license has been outlined in the pom and README entry added to outline
future policy when adding 3rd party depdendencies.
Some of the OutgoingConnection and RA tests were failing due to a
previous transaction being present when using the Arjuna TM. This patch
adds methods to allow tests which TM to use and ensures that Dummy TM is
cleaned up each after each test.
https://issues.apache.org/jira/browse/ACTIVEMQ6-67
fixed distribution so that file based security works and hot deployers as broken and no longer needed with new bootstrap.
Also combined the jms and core configuration files.
Implements a new feature for the broker whereby it may automatically
create and delete JMS queues which are not explicitly defined through
the management API or file-based configuration. A JMS queue is created
in response to a sent message or connected consumer. 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-68
The logic on transferring method is a bit complex, where
I found a better way to calculate the targetIDs.
This will also fix a few ScaleDownTests
I also added some extra tests using ScaleDownDirect
Some of the outgoing connection tests require a dummy transaction
manager to setup a fake transaction. The default transaction manager is
set to the JBoss TX manager and so the tests were failing. This patch
split the OutgoingConnectionTest into ones that require a real TM
manager vs Dummy TM Manager.
.
https://issues.apache.org/jira/browse/ACTIVEMQ6-64
The redelivery list was not isolated on the PageIterator. This is moving the
redelivery list to the Iterator so we would have proper isolation of the functionality.
The previous version was assuming a single instance of PageIterator, QueueImpl and PageSubscription.
When we started using more than one instance of the Iterator we created this bug.
- added missing license headers found by maven rat plugin.
most of them added automatically via apache-rat
a few manually added
- added apache-rat maven plugin to the build cycle
on the replication channel
The connection-ttl and client-failure-check-period are not passed
to the server locator used to create replication connection. So the
fix sets the two parameters in SharedNothingBackupActivation.
The bridge currently tries to assign a TM even when the quality of
service level is set to Duplicates OK. This QoS does not use or require
a TM. This patch stops the bridge from attempting to assign a TM for
this QoS and also checks that a TM is set of the other QoS. If TM is
not set for a QoS that requires one, a error is logged and RunTime
exception thrown.
Some tests require a proper TM to be returned by the TMLocator
implementation whilst others require a DummyTM to be returned. This
patch makes allows TM returned by the locator class to be changed by the
test.
https://issues.apache.org/jira/browse/ACTIVEMQ6-54
Changing the order of depaging introduced an extra check that needs to be checked now.
This will probably take care of the issue by checking if the page is complete before depage.
Pulls out WildFly XA Recovery specifics into a different project. Some
XA recovery code is still present and is used as integration points for
integrating TM XA recovery processes.
https://issues.apache.org/jira/browse/ACTIVEMQ6-6
Removed the jboss security implementations and also implemented the location of Transaction Managers using Service Loader and removed the jboss implementation.
https://issues.apache.org/jira/browse/ACTIVEMQ6-54
This is fixing a few issues around paging:
- Browsing it not looking towards Paging. I'm using the queue.totalIterator which is a read-only iterator that goes towards the pages messages.
- Depage is not kicking correctly in some scenarios. I have improved the logic on scheduling depage for that.
https://issues.apache.org/jira/browse/ACTIVEMQ6-20
this has been identified as a dead feature.
It was only useful for presentations...
it had its time and we have better examples we can use...
It's time for this feature to go!
Adds a new service extensions components used to house any extension
points for integration and extension. In addition this patch adds
initial extension points for XAResource wrapping.