activemq
Miklos Espak
Herrick, Rick
You're working with the tip of the xnat_builder_1_6dev repo, I'm guessing?
We just added that MQ functionality to the server to handle prearchive session rebuild requests via queuing instead of just trying to do everything all at once. The MQ stuff is set up in the mq-context.xml configuration file. I haven’t seen this particular error message from that, but I’m not surprised: we’re still trying to roll these changes onto dev servers to validate function of the MQ implementation.
So I’m pretty certain there’s a way to configure this in the <amq:broker> element in that configuration file. I’m not certain what that way IS, but I’m certain there’s a way. I’ll look into it when I get a chance, which will later this afternoon or tomorrow morning, or you can try to run with it and see if you can find something. Unfortunately, the options here are VERY poorly documented (as in, they’re by and large not documented at all), so it’s not as easy as looking up how to do it.
Rick Herrick
Sr. Programmer/Analyst
Neuroinformatics Research Group
Washington University School of Medicine
--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
xnat_discussi...@googlegroups.com.
To post to this group, send email to
xnat_di...@googlegroups.com.
Visit this group at
http://groups.google.com/group/xnat_discussion?hl=en.
For more options, visit
https://groups.google.com/groups/opt_out.
The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.
Miklos Espak
I upgraded to the tip hoping that it solves anorher issue. (See my other email). So, I do not really need this prearchive controlling feature. I do not see for now if this error causes any trouble. Do you think it can?
Maybe I can just ignore it?
Cheers,
Miklos
Herrick, Rick
I’m reasonably certain it won’t cause any issues as long as you don’t use great quantities of temp storage space for the queued messages. Since those messages are really very lightweight, you shouldn’t run into any actual problems.
That said, I’ve managed to work my way through the XSD describing the amq namespace and have come up with the following somewhat awkward but successfully instantiated formulation:
<!-- embedded ActiveMQ Broker -->
<amq:broker id="activeMQBroker" brokerName="activeMQBroker" useJmx="false" persistent="true" schedulerSupport="false">
<amq:persistenceAdapter>
<!-- We'll use XNAT's data source, make sure the Spring ID matches. (For unit testing it's provided by the Spring test
context) Also, turning off locking, as we've no need for it with a single broker, and it was causing errors in the ActiveMQ
cleanup threads. -->
<amq:jdbcPersistenceAdapter dataSource="#dataSource" useLock="false" />
</amq:persistenceAdapter>
<amq:systemUsage>
<amq:systemUsage>
<amq:tempUsage><amq:tempUsage limit="32mb"/></amq:tempUsage>
</amq:systemUsage>
</amq:systemUsage>
</amq:broker>
The change is just the highlighted section. I say it’s awkward because of those double XML elements, i.e. amq:systemUsage inside another amq:systemUsage for no clear reason. That said, it seems to work. Give it a try and see if that eliminates your error message.
There are also tags that are parallel to amq:tempUsage for amq:memoryUsage and amq:storeUsage. I think you can also create a whole temp data store repository and just wire that in, but that’s getting more complex than we’d really want to be in our default configuration.
Also, you can create a properties file to allow for centralized administration of these run-time values, something like this:
mq.properties:
system.usage.temp=32mb
system.usage.memory=256mb
system.usage.store=512mb
And in your mq-context.xml:
<context:property-placeholder location="WEB-INF/conf/mq.properties" />
<amq:systemUsage>
<amq:systemUsage>
<amq:tempUsage><amq:tempUsage limit="${system.usage.temp}"/></amq:tempUsage>
<amq:memoryUsage><amq:memoryUsage limit="${system.usage.memory }"/></amq:memoryUsage>
<amq:storeUsage><amq:storeUsage limit="${system.usage.store}"/></amq:storeUsage>
</amq:systemUsage>
</amq:systemUsage>
Give that a try and please let me know how that works for you! Since I’m not seeing any errors in my deployments, I definitely want to try to get in what we need to reduce issues for new deployments…
Miklos Espak
I will give it a try tomorrow. However, I'm not sure where to place that file.
Cheers,
Miklos
Herrick, Rick
Sorry, that would probably help, wouldn’t it?
To test the fix, you can just replace the existing mq-context.xml, which is located under your XNAT web app in the folder WEB-INF/conf. Assuming that that works, I’ll check the changes into the repository and then they’ll be available in the default configurations for the dev tip.