[JBoss JIRA] (AS7-6715) JBOSS 7 won't start with many OSGi deployed bundles
by Jan Reznik (JIRA)
[ https://issues.jboss.org/browse/AS7-6715?page=com.atlassian.jira.plugin.s... ]
Jan Reznik commented on AS7-6715:
---------------------------------
Unfortunately, I haven't got a sample set.
Yes, I have 106 bundles and restarting the server quite often.
I've tried setting them as capabilities and then all bundles resolved and were activated OK. (Apart from the fact that WABs' contexts were not registered).
> JBOSS 7 won't start with many OSGi deployed bundles
> ---------------------------------------------------
>
> Key: AS7-6715
> URL: https://issues.jboss.org/browse/AS7-6715
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final)
> Environment: Red Hat Enterprise Linux Server release 5.9
> java version "1.7.0_13" 64-bit
> 8 core CPU
> Reporter: Jan Reznik
> Assignee: Thomas Diesler
> Attachments: thread-dumps.zip
>
>
> JBOSS 7.2.0.Final randomly fails to start when deploying many (100+) OSGi bundles.
> In the Linux environment with fast CPU it fails 3 out of 5 times. In lower spec Windows 32 bit environment it only fails every now and then.
> 3 different thread dumps are attached.
--
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
13 years, 3 months
[JBoss JIRA] (JGRP-1594) UNICAST3: introduce connection establishment / teardown
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1594?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1594:
--------------------------------
I picked solution #1:
* When a connection is closed, it won't get removed immediately, but marked as CLOSING (from OPEN)
* After conn_close_timeout ms of no access, the connection will be marked as CLOSED and removed
* Message batching was also changed:
** When a batch is received, we check if it contains messages with first=true
** If true, we grab a new ReceiverEntry
** Else we grab the existing ReceiverEntry
** Then all messages of the batch are added to the receiver window *in one operation* (locks are acquired only once)
> UNICAST3: introduce connection establishment / teardown
> -------------------------------------------------------
>
> Key: JGRP-1594
> URL: https://issues.jboss.org/browse/JGRP-1594
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> [Use case: UNICAST_ConnectionTests.testBClosingUnilaterally()]
> There can be issues when simply sending messages with a conn-id, and the peer closing the connection, e.g.:
> * A and B have connections (send,receive) to each other
> * A sends 10 messages to B on conn-id=1
> * B accepts the 10 messages and passes them up
> * B closes its connection (but hasn't sent ack(10) yet)
> ** Closing the connection, B removes the receive table for A
> * A hasn't received an ACK so it resends the 10 messages with conn-id=1
> * B creates a new connection for A and a new (empty) receive table
> ** B now accepts the 10 *retransmitted* messages from A and delivers them
> B therefore delivers the 10 messages *twice* !
> SOLUTION #1:
> * When closing a connection, don't *remove* it immediately, but only mark is as closed and keep it around for a few minutes
> * A reaper then removes connections that have been marked as closed and have been idle for a few minutes
> ** If messages are received for a closed connection on the same conn-id, remove the closed mark and treat the connection as open again
> *** If A resent the 10 messages, B would still have the receive window, and know that it already received the 10 messages from A and discard them, preventing duplicate delivery
> SOLUTION #2:
> * Introduce explicit connection establishment and teardown, similar to TCP
> * When creating a connection to B, run a simplified SYN-ACK protocol, whereby both parties establish their sending and receiving conn-ids (perhaps also seqnos)
> * When closing a connection, run a simplified FIN-ACK protocol
> ** This would prevent A from resendin the 10 messages, as the send table would have been removed
> * Connection creation and teardown should be time bounded, ie. if a connection cann be created to a peer after some attempts and timeout, throw an exception, which propagates back to the caller, If a connection cannot be closed (e.g. no ACK is received for the FIN), simply close it unilaterally
--
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
13 years, 3 months
[JBoss JIRA] (AS7-5188) WS-Addressing Action on response is not being returned as specified in the WSDL
by Jim Ma (JIRA)
[ https://issues.jboss.org/browse/AS7-5188?page=com.atlassian.jira.plugin.s... ]
Jim Ma updated AS7-5188:
------------------------
Attachment: addr_action.zip
greetmebare-output.txt
> WS-Addressing Action on response is not being returned as specified in the WSDL
> -------------------------------------------------------------------------------
>
> Key: AS7-5188
> URL: https://issues.jboss.org/browse/AS7-5188
> Project: Application Server 7
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 7.1.2.Final (EAP)
> Environment: AS7, SOA 5.2
> Reporter: Jakob Munih
> Assignee: Jim Ma
> Labels: addressing
> Attachments: addr_action.zip, greetmebare-output.txt, RespondingGatewayDeferred.java, soa52.txt
>
>
> According to https://issues.apache.org/jira/browse/CXF-2629 its should be implemented that a WS method call can be overridden by the wsaw:Action or better by the @Action annotation. With jbossWS in AS7 and in SOA5.2 this is not honored.
> As show from the soa52.txt log file, having two methods with the same inbound input but different wsaw:Action the same method is called every time. In the occasion where the right return type is triggered the outbound body rightfully contains the MCCI_IN000002UV01 object representation. With the wsaw:Action referring the the other method (the same method is called as before) an empty body is replied. AS7 is a little bit more clever. It replies in the second occasion throws an SoapFault that the method not supported. Seem that CXF try to handle the situation, but there are some problems in the INVOKE phrase between jboss-ws and the deployed endpoint call.
> The web service is created with maven org.apache.cxf:cxf-codegen-plugin that correctly adds @Action from the interface created from the wsdl. And the implementation has @Addressing(required = true, enabled = true) annotation and sending and request without the addressing headers correctly refuses the inbound message.
--
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
13 years, 3 months
[JBoss JIRA] (AS7-5188) WS-Addressing Action on response is not being returned as specified in the WSDL
by Jim Ma (JIRA)
[ https://issues.jboss.org/browse/AS7-5188?page=com.atlassian.jira.plugin.s... ]
Jim Ma commented on AS7-5188:
-----------------------------
Hi Jakob, do you have a war file I can reproduce this issue ? I tested this with attached test classes and wsdl in AS-7.1.2.Final, I didn't see this issue. Can you please have a look my test code to see if there is any difference ?
> WS-Addressing Action on response is not being returned as specified in the WSDL
> -------------------------------------------------------------------------------
>
> Key: AS7-5188
> URL: https://issues.jboss.org/browse/AS7-5188
> Project: Application Server 7
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 7.1.2.Final (EAP)
> Environment: AS7, SOA 5.2
> Reporter: Jakob Munih
> Assignee: Jim Ma
> Labels: addressing
> Attachments: RespondingGatewayDeferred.java, soa52.txt
>
>
> According to https://issues.apache.org/jira/browse/CXF-2629 its should be implemented that a WS method call can be overridden by the wsaw:Action or better by the @Action annotation. With jbossWS in AS7 and in SOA5.2 this is not honored.
> As show from the soa52.txt log file, having two methods with the same inbound input but different wsaw:Action the same method is called every time. In the occasion where the right return type is triggered the outbound body rightfully contains the MCCI_IN000002UV01 object representation. With the wsaw:Action referring the the other method (the same method is called as before) an empty body is replied. AS7 is a little bit more clever. It replies in the second occasion throws an SoapFault that the method not supported. Seem that CXF try to handle the situation, but there are some problems in the INVOKE phrase between jboss-ws and the deployed endpoint call.
> The web service is created with maven org.apache.cxf:cxf-codegen-plugin that correctly adds @Action from the interface created from the wsdl. And the implementation has @Addressing(required = true, enabled = true) annotation and sending and request without the addressing headers correctly refuses the inbound message.
--
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
13 years, 3 months
[JBoss JIRA] (DROOLS-79) ClassCastException when compiling a rule
by Radai Rosenblatt (JIRA)
Radai Rosenblatt created DROOLS-79:
--------------------------------------
Summary: ClassCastException when compiling a rule
Key: DROOLS-79
URL: https://issues.jboss.org/browse/DROOLS-79
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.5
Reporter: Radai Rosenblatt
Assignee: Mark Proctor
when compiling a rule on jboss i see this exception printed out to the log:
2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) Exception in thread "Thread-264" java.lang.ClassCastException: org.mvel2.compiler.ExecutableLiteral cannot be cast to org.mvel2.compiler.ExecutableAccessor
2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:173)
2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:174)
2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:108)
2013-03-13 10:54:37,517 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
2013-03-13 10:54:37,518 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
2013-03-13 10:54:37,518 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
2013-03-13 10:54:37,673 ERROR [stderr] (Thread-264) at java.lang.Thread.run(Thread.java:722)
so far i've not been able to reproduce this issue stand-alone
--
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
13 years, 3 months
[JBoss JIRA] (DROOLS-78) NullPointerException in windows eviction
by Radai Rosenblatt (JIRA)
[ https://issues.jboss.org/browse/DROOLS-78?page=com.atlassian.jira.plugin.... ]
Radai Rosenblatt updated DROOLS-78:
-----------------------------------
Summary: NullPointerException in windows eviction (was: NullPointerException in Length Window)
Description:
when writing a (fusion) rule with a length window and inserting more events than the window size drools produces a null pointer exception on the 1st event over the window size.
the exception produced is:
java.lang.NullPointerException
at org.drools.core.util.index.RightTupleIndexHashTable.remove(RightTupleIndexHashTable.java:363)
at org.drools.reteoo.AccumulateNode.retractRightTuple(AccumulateNode.java:318)
at org.drools.rule.SlidingLengthWindow.assertFact(SlidingLengthWindow.java:116)
at org.drools.rule.BehaviorManager.assertFact(BehaviorManager.java:94)
at org.drools.reteoo.WindowNode.assertObject(WindowNode.java:167)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:127)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:55)
a similar exception happens when the rule is re-written to use a time window (and the test updated to overflow that window):
org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.rule.SlidingTimeWindow$BehaviorExpireWMAction@1dc39fc3
at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:995)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:335)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:127)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:55)
at TestBug2.testBug(TestBug2.java:96)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:76)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.NullPointerException
at org.drools.core.util.index.RightTupleIndexHashTable.remove(RightTupleIndexHashTable.java:363)
at org.drools.reteoo.AccumulateNode.retractRightTuple(AccumulateNode.java:318)
at org.drools.rule.SlidingTimeWindow.expireFacts(SlidingTimeWindow.java:189)
at org.drools.rule.SlidingTimeWindow$BehaviorExpireWMAction.execute(SlidingTimeWindow.java:471)
at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:993)
... 31 more
was:
when writing a (fusion) rule with a length window and inserting more events than the window size drools produces a null pointer exception on the 1st event over the window size.
the exception produced is:
java.lang.NullPointerException
at org.drools.core.util.index.RightTupleIndexHashTable.remove(RightTupleIndexHashTable.java:363)
at org.drools.reteoo.AccumulateNode.retractRightTuple(AccumulateNode.java:318)
at org.drools.rule.SlidingLengthWindow.assertFact(SlidingLengthWindow.java:116)
at org.drools.rule.BehaviorManager.assertFact(BehaviorManager.java:94)
at org.drools.reteoo.WindowNode.assertObject(WindowNode.java:167)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:127)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:55)
> NullPointerException in windows eviction
> ----------------------------------------
>
> Key: DROOLS-78
> URL: https://issues.jboss.org/browse/DROOLS-78
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5
> Reporter: Radai Rosenblatt
> Assignee: Mark Proctor
> Attachments: droolsIssue.zip
>
>
> when writing a (fusion) rule with a length window and inserting more events than the window size drools produces a null pointer exception on the 1st event over the window size.
> the exception produced is:
> java.lang.NullPointerException
> at org.drools.core.util.index.RightTupleIndexHashTable.remove(RightTupleIndexHashTable.java:363)
> at org.drools.reteoo.AccumulateNode.retractRightTuple(AccumulateNode.java:318)
> at org.drools.rule.SlidingLengthWindow.assertFact(SlidingLengthWindow.java:116)
> at org.drools.rule.BehaviorManager.assertFact(BehaviorManager.java:94)
> at org.drools.reteoo.WindowNode.assertObject(WindowNode.java:167)
> at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
> at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:127)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:55)
> a similar exception happens when the rule is re-written to use a time window (and the test updated to overflow that window):
> org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.rule.SlidingTimeWindow$BehaviorExpireWMAction@1dc39fc3
> at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:995)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:335)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:127)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:55)
> at TestBug2.testBug(TestBug2.java:96)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:76)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.NullPointerException
> at org.drools.core.util.index.RightTupleIndexHashTable.remove(RightTupleIndexHashTable.java:363)
> at org.drools.reteoo.AccumulateNode.retractRightTuple(AccumulateNode.java:318)
> at org.drools.rule.SlidingTimeWindow.expireFacts(SlidingTimeWindow.java:189)
> at org.drools.rule.SlidingTimeWindow$BehaviorExpireWMAction.execute(SlidingTimeWindow.java:471)
> at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:993)
> ... 31 more
--
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
13 years, 3 months