[JBoss JIRA] (JGRP-1737) TP: ignore DONT_BUNDLE flag for sending of messages
by Bela Ban (JIRA)
Bela Ban created JGRP-1737:
------------------------------
Summary: TP: ignore DONT_BUNDLE flag for sending of messages
Key: JGRP-1737
URL: https://issues.jboss.org/browse/JGRP-1737
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
Currently, messages tagged with DONT_BUNDLE are sent separately, not as a message bundle through a bundler. On the receiver, they are passed up as single messages, ie. on a separate thread.
Sending a lot of single (possibly small) messages is inefficient; it would be better to bundle *all* message on the sender side. This requires a bundler which sends single messages immediately when no other messages are available to be sent.
SOLUTION (sender):
* If the bundler is *not* "old", ignore the DONT_BUNDLE flag and send the message through the bundler
* Else, same as now; send the message immediately as single message
SOLUTION (receiver):
* When reading the message list and creating the 4 batches (regular, oob, oob+internal, internal), if a message has DONT_BUNDLE set, pass it as single message to the corresponding thread pool and don't add it to the batch
This has the advantage that we have a more efficient way of sending messages (as message bundles), yet the behavior (and performance) at the receiver is the same as now
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment status is FAILED but application running well
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.s... ]
Alexey Loubyansky updated WFLY-880:
-----------------------------------
Assignee: Brian Stansberry (was: Alexey Loubyansky)
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
> Key: WFLY-880
> URL: https://issues.jboss.org/browse/WFLY-880
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Environment: suse linux 11 sp2
> Reporter: jing chen
> Assignee: Brian Stansberry
> Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
> "outcome" => "success",
> "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2469) Upgrade to HornetQ 2.4.0.CR1
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-2469:
---------------------------------
Summary: Upgrade to HornetQ 2.4.0.CR1
Key: WFLY-2469
URL: https://issues.jboss.org/browse/WFLY-2469
Project: WildFly
Issue Type: Component Upgrade
Security Level: Public (Everyone can see)
Components: JMS
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 8.0.0.CR1
HornetQ 2.4.0.CR1 depends on Netty 4.0.x versions that broke compatibility with Netty 3.x
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2454) Cannot stop recovery manager when configured with volatile store
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-2454?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-2454:
-------------------------------------
Hi gui,
Please can you add the steps to reproduce this, including your customer properties file and where you are specifying your om.arjuna.ats.arjuna.common.propertiesFile property.
Many thanks,
Tom
> Cannot stop recovery manager when configured with volatile store
> ----------------------------------------------------------------
>
> Key: WFLY-2454
> URL: https://issues.jboss.org/browse/WFLY-2454
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Beta1
> Reporter: gui borland
> Assignee: Tom Jenkinson
>
> When using jboss 5, i was able to configure a 'Volatile' action store. I understand it's not the most robust store, but in my case performance is more important than tx consistency.
> I tried to configure the Volatile store in AS 7.1.3 as well (using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting ), but doing that breaks the recovery thread. It prints out a warning message (Volatile storage does not support recovery blablabla...). That would be fine, but this recovery issue also prevents jboss from shutting down cleanly. I have to kill it to stop it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-1893) Restarting server with a disabled DS enables the DS
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1893?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1893:
-----------------------------------------------
Stefano Maestri <smaestri(a)redhat.com> made a comment on [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277]
Attention: Russel Dickenson
Release note text: enabled attribute is correctly marshaled on xml when :disable operation is used.
Let me know if you need something else.
> Restarting server with a disabled DS enables the DS
> ---------------------------------------------------
>
> Key: WFLY-1893
> URL: https://issues.jboss.org/browse/WFLY-1893
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Reporter: Kabir Khan
> Assignee: Stefano Maestri
>
> See https://issues.jboss.org/browse/WFLY-1874
> If you add a datasource with
> subsystem=datasources/data-source=Test:add(jndi-name=java:/Test,jta=false,use-ccm=false,connection-url=url,driver-class=org.h2.Driver,driver-name=h2,user-name=user,password=pass,validate-on-match=false,background-validation=false,share-prepared-statements=false)
> it shows up as not enabled/undefined:
> {code}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=Test:read-resource{ "outcome" => "success",
> "result" => {
> ...
> "enabled" => false,
> {code}
> {code}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=Test:read-resource(include-defaults=false)
> {
> "outcome" => "success",
> "result" => {
> ... "enabled" => undefined,
> {code}
> This is persisted as
> {code}
> <datasource jta="false" jndi-name="java:/Test" pool-name="Test" enabled="false" use-ccm="false">
> <connection-url>url</connection-url>
> <driver-class>org.h2.Driver</driver-class>
> <driver>h2</driver>
> <security>
> <user-name>user</user-name>
> <password>pass</password>
> </security>
> <validation>
> <validate-on-match>false</validate-on-match>
> <background-validation>false</background-validation>
> </validation>
> <statement>
> <share-prepared-statements>false</share-prepared-statements>
> </statement>
> </datasource>
> {code}
> Now if you stop and start the server again you end up with enabled=true.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-1933) Disabled data-source without explicit enabled="false" in configuration xml file is re-enabled again after server reload
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1933?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1933:
-----------------------------------------------
Stefano Maestri <smaestri(a)redhat.com> made a comment on [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277]
Attention: Russel Dickenson
Release note text: enabled attribute is correctly marshaled on xml when :disable operation is used.
Let me know if you need something else.
> Disabled data-source without explicit enabled="false" in configuration xml file is re-enabled again after server reload
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1933
> URL: https://issues.jboss.org/browse/WFLY-1933
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Alpha4
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> The server automatically re-enables a data-source which was disabled before and which lost {{enabled="false"}} in the configuration XML file.
> There is a discrepancy between the default value of the {{enabled}} attribute in XSD and the same attribute definition in org.jboss.as.connector.subsystems.datasources.Constants. From my POV any data-source that has been disabled before should stay in that state unless it is explicitly enabled again. See https://bugzilla.redhat.com/show_bug.cgi?id=952277 for a reproducer.
> The culprit seems to be
> {code:java|title=org.jboss.as.connector.subsystems.datasources.DsParser}
> ...
> private void parseDataSource(final XMLExtendedStreamReader reader, final List<ModelNode> list, final ModelNode parentAddress) throws XMLStreamException, ParserException,
> ValidateException {
> ...
> ==> boolean enabled = Defaults.ENABLED.booleanValue();
> ...
> private void parseXADataSource(XMLExtendedStreamReader reader, final List<ModelNode> list, final ModelNode parentAddress) throws XMLStreamException, ParserException,
> ValidateException {
> ...
> ==> boolean enabled = Defaults.ENABLED.booleanValue();
> ...
> {code}
> Though it looks like a bug, I am not sure we can change the default value in XSD for EAP.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-1716) NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
by Oliver Pfau (JIRA)
[ https://issues.jboss.org/browse/WFLY-1716?page=com.atlassian.jira.plugin.... ]
Oliver Pfau commented on WFLY-1716:
-----------------------------------
Tried with wildfly 8.0.0 beta 2 build 773 and I get the exception:
08:43:28,204 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."my-war.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."my-war.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "my-war.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_45]
at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_45]
Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache
at org.wildfly.extension.undertow.deployment.ELExpressionFactoryProcessor.deploy(ELExpressionFactoryProcessor.java:78)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
... 5 more
> NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-1716
> URL: https://issues.jboss.org/browse/WFLY-1716
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE
> Affects Versions: 8.0.0.Alpha3
> Environment: Win 7, JEE 6, JDK 7
> Reporter: Oliver Pfau
> Assignee: Stuart Douglas
> Labels: Deploy, classnotfound, war
>
> I tried to deploy my ear which works in JBoss 7 in wildfly and got the following error on deploy:
> 09:59:55,060 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "mywar.war" of deployment "my.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache
> at org.wildfly.extension.undertow.deployment.ELExpressionFactoryProcessor.deploy(ELExpressionFactoryProcessor.java:78)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> ... 5 more
> 09:59:55,100 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "my.ear")]) - failure description: {
> "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"mywar.war\" of deployment \"my.ear\"
> Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache"},
> "JBAS014771: Services with missing/unavailable dependencies" => [
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.ValidatorFactory is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.InstanceName is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.Validator is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>
> <all other services>
> ]
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2125) wildfly8 can't identify port-offset
by Isa Isa (JIRA)
[ https://issues.jboss.org/browse/WFLY-2125?page=com.atlassian.jira.plugin.... ]
Isa Isa commented on WFLY-2125:
-------------------------------
Hi I am using wildfly-8.0.0.Beta1 and mod_cluster still does not picking up the port offset? It only identifies what is set in the standalone.xml.
If the offset is 100 then ajp would be 8109 which is does not identify, however if I set the ajp port in the standalone.xml to 8109 with no offset it works.
> wildfly8 can't identify port-offset
> -----------------------------------
>
> Key: WFLY-2125
> URL: https://issues.jboss.org/browse/WFLY-2125
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Alpha4
> Environment: wildfly-8.0.0.Alpha4.tar.gz
> jdk-7u25-linux-i586.rpm
> mod_cluster-1.2.0.Final-linux2-x64-ssl.tar.gz
> Reporter: hui gao
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.Beta1
>
>
> I installed wildfly8 and mod_cluster reference steps of https://docs.jboss.org/author/display/AS72/AS7+Cluster+Howto
> The cluster contains four servers,start up with domain mode:
> 10.19.222.52:server1/server2
> 10.19.222.53:server3/server4
> 10.19.222.50:apache
> But it only detects server1 and server3 which the port is 8009.
> The port-offset is 100,it can't identify the other port(8109) for server2 and server4.
> Search errorlog of Apache ,the proxy:AJP always acquired connection through initial AJP port(8009) defined in domain.xml.
> [Fri Sep 13 21:07:40 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:40 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=2644d861-0ead-352c-ba1e-619f1e1f25e8&Load=100"
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2366): manager_handler STATUS OK
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=ea81701b-f847-34a8-9534-0ac5c489af90&Load=100"
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (JGRP-1736) UDP: Android does not reset buffer length
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1736?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1736.
----------------------------
Resolution: Done
> UDP: Android does not reset buffer length
> -----------------------------------------
>
> Key: JGRP-1736
> URL: https://issues.jboss.org/browse/JGRP-1736
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.1, 3.5
>
>
> Discussion at http://jgroups.1086181.n5.nabble.com/jgroups-users-PLEASE-HELP-ME-OUT-FOR...:
> Hi, Belaban..I think I have found the problem...after discovering this issue occurs only on all ICS devices I have and after reading through the "Android issue #24748 DatagramPacket truncated UDP" at http://code.google.com/p/android/issues/detail?id=24748, I have introduced the following modification at org.jgroups.protocols.UDP.java:
> public void run() {
> final byte receive_buf[]=new byte[66000]; // to be on the safe side (IPv6 == 65575 bytes, IPv4 = 65535)
> final DatagramPacket packet=new DatagramPacket(receive_buf, receive_buf.length);
> while(thread != null && Thread.currentThread().equals(thread)) {
> try {
>
> //Solved Android ISSUE #24748 - DatagramPacket truncated UDP in ICS
> if (Util.checkForAndroid())
> packet.setLength(receive_buf.length);
>
> receiver_socket.receive(packet);
> int len=packet.getLength();
>
> ...
> }
> catch(SocketException sock_ex) {
> ...
> }
> catch(Throwable ex) {
> ...
> }
> }
> ...
> }
> It seems to solve the EOFException but I am not sure the real impact on Jgroups library as a whole.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months