[
https://issues.apache.org/jira/browse/ARTEMIS-2490?focusedWorklogId=314239&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-314239
]
ASF GitHub Bot logged work on ARTEMIS-2490:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 18/Sep/19 10:41
Start Date: 18/Sep/19 10:41
Worklog Time Spent: 10m
Work Description: MrEasy commented on pull request #2839: [ARTEMIS-2490]
Prevent NumberFormatExc when reading large message
URL: https://github.com/apache/activemq-artemis/pull/2839#discussion_r325603848
##########
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/persistence/impl/journal/JournalStorageManager.java
##########
@@ -369,12 +369,11 @@ protected SequentialFile createFileForLargeMessage(final
long messageID, final b
LargeMessagePersister.getInstance().decode(buff, largeMessage);
if (largeMessage.containsProperty(Message.HDR_ORIG_MESSAGE_ID)) {
- // for compatibility: couple with old behaviour, copying the old file
to avoid message loss
- long originalMessageID =
largeMessage.getLongProperty(Message.HDR_ORIG_MESSAGE_ID);
Review comment:
Problem is that you can set the Core-message-ID and feed it with a
non-number. This then fails when reading it on journal initialization.
The format "ID:<UUID>" is used as JMS-message-id (in contrast to
core-message-id), so this seems to end-up sometimes as core-message-id as well.
In any case, I would like to request the retrieval to be moved inside the
compatibility block, since it is just unneeded outside.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 314239)
Time Spent: 40m (was: 0.5h)
> JournalStorageManager#parseLargeMessage may produce fatal issue when reading
> ORIG_ID
> ------------------------------------------------------------------------------------
>
> Key: ARTEMIS-2490
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2490
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 2.10.0
> Reporter: Rico Neubauer
> Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Preface: Found the issue initially with HornetQ and Stacktrace below is from
> HornetQ, but checked Artemis and issue there exists in the same manner.
> If there is a large-message in journal, this gets parsed on startup while
> doing initialization.
> While doing that property "__AMQ_ORIG_MESSAGE_ID_" (in HornetQ "HQ" instead
> of "AMQ") is always read, _for compatibility_ according to code.
> Problem with that: In case the property does not hold a number, but sth. like
> "_ID:c6e2e3..._", then a NumberFormatException is thrown, which falls thru
> the entire initialization mechanism and leads to a non-functioning server.
> I have no idea, who sets this, but seems internally, since we have no code
> doing this. Looks like a JMS-Message-ID to me.
> Mabye this whole compatibility code is not needed anymore - cannot say
> though.
> What I would like to request:
> # Move the retrieval of the property inside the compatibility-block in
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.parseLargeMessage
> - since it is not needed otherwise and already avoids the issue in the vast
> majority where no compatibility must be done.
> # -In addition, a check for the "ID:" prefix and removing it before parsing
> to Long.-
> Edit: Sorry that was wrong, but:
> Adding a try for parsing to Long and handling not-a-number gracefully, so
> server continues startup.
> See PR for first.
> Just fyi: the fix for HornetQ: [Github (containing wrong logic for
> parsing)|https://github.com/seeburger-ag/hornetq/commit/8ef99744f219b23d76803435201e4af33a53b3c5]
> Stacktrace (as said: based on HornetQ code, but class- and method-names are
> the same):
> {code:java}
> Failure in initialisation: java.lang.NumberFormatException: For input string:
> "ID:c6e2e367-d77e-11e9-9471-005056b7cdce"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Long.parseLong(Long.java:589)
> at java.lang.Long.parseLong(Long.java:631)
> at
> org.hornetq.utils.TypedProperties.getLongProperty(TypedProperties.java:330)
> at
> org.hornetq.core.message.impl.MessageImpl.getLongProperty(MessageImpl.java:762)
> at
> org.hornetq.core.persistence.impl.journal.JournalStorageManager.parseLargeMessage(JournalStorageManager.java:1764)
> at
> org.hornetq.core.persistence.impl.journal.JournalStorageManager.loadMessageJournal(JournalStorageManager.java:953)
> at
> org.hornetq.core.server.impl.HornetQServerImpl.loadJournals(HornetQServerImpl.java:1603)
> at
> org.hornetq.core.server.impl.HornetQServerImpl.initialisePart2(HornetQServerImpl.java:1445)
> at
> org.hornetq.core.server.impl.HornetQServerImpl.access$1200(HornetQServerImpl.java:138)
> at
> org.hornetq.core.server.impl.HornetQServerImpl$SharedStoreLiveActivation.run(HornetQServerImpl.java:1919)
> at
> org.hornetq.core.server.impl.HornetQServerImpl.start(HornetQServerImpl.java:366)
> at
> org.hornetq.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:269)
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
