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
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
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
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.
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.
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.
https://issues.apache.org/jira/browse/ACTIVEMQ6-44
The DiscoveryGroup should be resilient to failures on the communication.
We shouldn't kill the Loop if an exception happened during the read of the UDP messages.
https://issues.apache.org/jira/browse/ACTIVEMQ6-3
We are renaming packages from activemq6 to activemq as that's more generic and version independent
The previous commit renamed the directories. On this commit now I'm changing the code.
If we changed the code and the directories on the same commit git would remove and add a lot of files
without recognizing the renames.
https://issues.apache.org/jira/browse/ACTIVEMQ6-3
We are renaming packages from activemq6 to activemq as that's more generic and version independent
On this first commit I'm just renaming the directories otherwise the history would be lost. The next commit will rename the text on the directories.
If I squash these two commits git will make us delete / add again.