[JBoss JIRA] (ISPN-6671) Transactions committed immediately before cache stop can block shutdown
by Brad Maxwell (JIRA)
Brad Maxwell created ISPN-6671:
----------------------------------
Summary: Transactions committed immediately before cache stop can block shutdown
Key: ISPN-6671
URL: https://issues.jboss.org/browse/ISPN-6671
Project: Infinispan
Issue Type: Bug
Components: Core, Test Suite - Core
Affects Versions: 7.2.1.Final, 8.0.0.Alpha1
Reporter: Brad Maxwell
Assignee: Dan Berindei
Priority: Blocker
Fix For: 8.2.1.Final, 9.0.0.Alpha1, 8.1.4.Final
This is causing random failures in {{DistributedEntryRetrieverTxTest.verifyNodeLeavesBeforeGettingData}}.
The test inserts some values into the cache, starts an iteration, and then kills one of the nodes. In rare instances, the killed cache only receives the TxCompletionCommand for one of the writes after it started the shutdown, and ignores it. That leaves the remote tx on-going, and {{TransactionTable.shutDownGracefully()}} blocks for 30 seconds - causing a {{TimeoutException}} elsewhere in the test.
{noformat}
10:52:18,129 TRACE (remote-thread-NodeAM-p12133-t6:) [CommandAwareRpcDispatcher] About to send back response SuccessfulResponse{responseValue=null} for command CommitCommand {gtx=GlobalTransaction:<NodeAL-45757>:22325:remote, cacheName='org.infinispan.iteration.DistributedEntryRetrieverTxTest', topologyId=4}
10:52:18,129 TRACE (testng-DistributedEntryRetrieverTxTest:) [JGroupsTransport] dests=[NodeAM-45518, NodeAL-45757], command=TxCompletionNotificationCommand{ xid=null, internalId=0, topologyId=4, gtx=GlobalTransaction:<NodeAL-45757>:22325:local, cacheName=org.infinispan.iteration.DistributedEntryRetrieverTxTest} , mode=ASYNCHRONOUS, timeout=15000
10:52:18,133 DEBUG (testng-DistributedEntryRetrieverTxTest:) [CacheImpl] Stopping cache org.infinispan.iteration.DistributedEntryRetrieverTxTest on NodeAM-45518
10:52:18,133 TRACE (OOB-2,NodeAM-45518:) [GlobalInboundInvocationHandler] Attempting to execute CacheRpcCommand: TxCompletionNotificationCommand{ xid=null, internalId=0, topologyId=4, gtx=GlobalTransaction:<NodeAL-45757>:22325:local, cacheName=org.infinispan.iteration.DistributedEntryRetrieverTxTest} [sender=NodeAL-45757]
10:52:18,133 TRACE (OOB-2,NodeAM-45518:) [GlobalInboundInvocationHandler] Silently ignoring that org.infinispan.iteration.DistributedEntryRetrieverTxTest cache is not defined
10:52:18,133 DEBUG (testng-DistributedEntryRetrieverTxTest:) [TransactionTable] Wait for on-going transactions to finish for 30 seconds.
10:52:48,139 WARN (testng-DistributedEntryRetrieverTxTest:) [TransactionTable] ISPN000100: Stopping, but there are 0 local transactions and 1 remote transactions that did not finish in time.
10:52:48,386 ERROR (testng-DistributedEntryRetrieverTxTest:) [UnitTestTestNGListener] Test verifyNodeLeavesBeforeGettingData(org.infinispan.iteration.DistributedEntryRetrieverTxTest) failed.
java.lang.IllegalStateException: Thread already timed out waiting for event pre_send_response_released
at org.infinispan.test.fwk.CheckPoint.trigger(CheckPoint.java:131)
at org.infinispan.test.fwk.CheckPoint.trigger(CheckPoint.java:116)
at org.infinispan.iteration.DistributedEntryRetrieverTest.verifyNodeLeavesBeforeGettingData(DistributedEntryRetrieverTest.java:105)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ISPN-6670) Deadlock during server start
by Brad Maxwell (JIRA)
Brad Maxwell created ISPN-6670:
----------------------------------
Summary: Deadlock during server start
Key: ISPN-6670
URL: https://issues.jboss.org/browse/ISPN-6670
Project: Infinispan
Issue Type: Bug
Components: Core, Server
Affects Versions: 8.2.0.Final
Reporter: Brad Maxwell
Assignee: Dan Berindei
Priority: Critical
Fix For: 8.2.1.Final, 9.0.0.Alpha1, 8.1.4.Final
This happens frequently when starting servers in parallel, the more servers, the easier to reproduce.
Attached the stack trace of server1 and server2 after hanging.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ISPN-6669) org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly
by Brad Maxwell (JIRA)
Brad Maxwell created ISPN-6669:
----------------------------------
Summary: org.infinispan.transaction.xa.GlobalTransaction objects are not cleared properly
Key: ISPN-6669
URL: https://issues.jboss.org/browse/ISPN-6669
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 8.1.3.Final, 8.2.1.Final, 9.0.0.Alpha1
Reporter: Brad Maxwell
Assignee: Pedro Ruivo
Priority: Critical
Fix For: 9.0.0.Alpha2, 8.1.4.Final, 8.2.2.Final, 9.0.0.Final
The issue was spotted in 6 hr soak tests and affects both distributed & replicated mode.
The test shows steady increase in heap usage. After closer examination of jfr recording, it seems that at the end of the test there are almost 22M live org.infinispan.transaction.xa.GlobalTransaction instances in the heap, totaling 667 MB in size.
Top heap consumers (final stage of the test)
Class Instances Size(bytes) Percentage of Heap(%)
byte[] 60,218 830,445,604 35.168
Class Instances Size(bytes) Percentage of Heap(%)
org.infinispan.transaction.xa.GlobalTransaction 21,846,176 699,077,616 29.605
Class Instances Size(bytes) Percentage of Heap(%)
java.util.concurrent.ConcurrentHashMap$Node 21,795,718 697,462,992 29.537
Class Instances Size(bytes) Percentage of Heap(%)
java.util.concurrent.ConcurrentHashMap$Node[] 129 134,352,464 5.69
Transaction configuration:
<transaction transaction-manager-lookup="org.infinispan.transaction.lookup.GenericTransactionManagerLookup" mode="NON_DURABLE_XA" />
Please let me know if you'd like me to share more details from jfr recording.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ISPN-6668) Deadlock when a prepare command is retried
by Brad Maxwell (JIRA)
Brad Maxwell created ISPN-6668:
----------------------------------
Summary: Deadlock when a prepare command is retried
Key: ISPN-6668
URL: https://issues.jboss.org/browse/ISPN-6668
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.1.0.Final
Reporter: Brad Maxwell
Assignee: Pedro Ruivo
Fix For: 8.2.0.CR1, 8.1.4.Final
Looks like the ISPN-5623 fix went too far, and now I found a test failure with the opposite behaviour:
1. Remote prepare for {{txA}} acquires lock {{K}}
2. Remote prepare for {{txB}} blocks waiting for lock {{K}}
3. The topology changes, and the {{txA}} prepare is retried
4. The {{txA}} prepare times out, because it waits for pending transaction {{txB}} to finish.
So we have to make {{txA}} somehow know that it already has the lock after it received an {{UnsureResponse}} for the prepare command, and skip waiting for pending transactions.
I found the problem in a random failure of {{DistributedFourNodesMapReduceTest}} on a local branch, but I'm not sure if my local changes (making SyncCHF the default CH factory) made it more likely.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ISPN-6667) NullPointerException when executing RemoveExpiredCommand
by Brad Maxwell (JIRA)
Brad Maxwell created ISPN-6667:
----------------------------------
Summary: NullPointerException when executing RemoveExpiredCommand
Key: ISPN-6667
URL: https://issues.jboss.org/browse/ISPN-6667
Project: Infinispan
Issue Type: Bug
Components: Expiration
Affects Versions: 8.0.2.Final
Reporter: Brad Maxwell
Assignee: William Burns
Fix For: 9.0.0.Alpha2, 8.1.4.Final, 8.2.2.Final
I'm running Infinispan 8.0.2 in a clustered environment with a replicated cache with a single file cache store. I'm seeing some NullPointerExceptions when Infinispan executes the RemoveExpiredCommand. Here's a snippet from the stack trace:
{noformat}
ISPN000136: Error executing command RemoveExpiredCommand, writing keys [...large key here...]
...
Caused by: java.lang.NullPointerException: null
at org.infinispan.commands.write.RemoveExpiredCommand.setParameters(RemoveExpiredCommand.java:142)
{noformat}
Here's RemoveExpiredCommand#setParameters(...):
{code} @Override
public void setParameters(int commandId, Object[] args) {
if (commandId != COMMAND_ID) throw new IllegalStateException("Invalid method id");
int i = 0;
commandInvocationId = (CommandInvocationId) args[i++];
key = args[i++];
value = args[i++];
lifespan = (long) args[i++];
}{code}
Line 142 is the cast of assignment of {{args\[3\]}} to primitive type long, which is causing the NPE. lifespan is actually a Long, not a long, and the {{perform()}} method seems to anticipate null lifespans at line 72:
{code} // If the provided lifespan is null, that means it is a store removal command, so we can't compare lifespan
if (lifespan == null) {}{code}
Could this be fixed by simply changing the cast at line 142 from (long) to (Long)?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ISPN-6666) Infinispan can miss incoming commands with JGroupsChannelLookup
by Brad Maxwell (JIRA)
Brad Maxwell created ISPN-6666:
----------------------------------
Summary: Infinispan can miss incoming commands with JGroupsChannelLookup
Key: ISPN-6666
URL: https://issues.jboss.org/browse/ISPN-6666
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.2.0.CR1, 8.1.2.Final
Reporter: Brad Maxwell
Assignee: Dan Berindei
Fix For: 8.2.1.Final, 9.0.0.Alpha1, 8.1.4.Final, 9.0.0.Final
Normally, the JGroupsTransport startup sequence goes like this:
# Create the {{Channel}}
# Create the {{CommandAwareRpcDispatcher}} and install it as an {{UpHandler}}
# Connect the channel
This way, every {{RequestCorrelator}} message received by the channel is passed up to {{CommandAwareRpcDispatcher}}, which executes the appropriate command.
When using a {{JGroupsChannelLookup}}, the lookup implementation is allowed to return a {{Channel}} instance that is already connected ({{shouldConnect() == false}}). That means there is now a window where the channel doesn't have an {{UpHandler}}, and messages sent to this node are discarded.
Normally a node only receives commands after it sent a join request to the coordinator. There are however a few exceptions:
# On startup, {{LocalTopologyManagerImpl}} sends the join request to the JGroups coordinator, which may not have the {{UpHandler}} yet. This seems to be responsible for the recent hanging in {{ConcurrentStartTest}}. We have a workaround here, to use a smaller timeout on the {{CacheTopologyControlCommand(JOIN)}} command, and retry it on {{TimeoutException}}.
# When a node becomes coordinator, {{ClusterTopologyManagerImpl}} broadcasts a {{GET_STATUS}} request to all cluster members, and expects a response from each of them. The same workaround with a smaller timeout and retries might work here.
# In replicated mode, write commands are broadcasted to all cluster members. There is some commented out code in {{RpcManagerImpl.invokeRemotelyAsync()}} that might fix it by only waiting for responses from the cache topology members.
We should consider deprecating {{JGroupsChannelLookup.shouldConnect()}} and requiring that the channel is only connected by {{JGroupsTransport}}. Assuming that works with {{ForkChannel}}, of course.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ISPN-6665) StateTransferManager should be the first component to stop
by Brad Maxwell (JIRA)
Brad Maxwell created ISPN-6665:
----------------------------------
Summary: StateTransferManager should be the first component to stop
Key: ISPN-6665
URL: https://issues.jboss.org/browse/ISPN-6665
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.2.0.CR1
Reporter: Brad Maxwell
Assignee: Dan Berindei
Fix For: 8.2.1.Final, 9.0.0.Alpha1, 8.1.4.Final
When a cache stops, it first removes the component registry from the {{GlobalComponentsRegistry}}'s {{namedComponents}} map, which means the node (let's call it {{A}}) will reply with a {{CacheNotFoundResponse}} to any remote command.
Another node {{B}} trying to execute a write/transactional command will receive the {{CacheNotFoundResponse}}, assume that a new cache topology with id {{current topology id + 1}} is coming soon, and wait for that new topology before retrying.
Normally this is not a problem, because {{StateTransferManagerImpl.stop()}} sends a {{CacheTopologyControlCommand(LEAVE)}} to the coordinator quickly enough, then {{B}} receives the {{current topology id + 1}} topology and retries the command.
But in some cases, the cache components that stop before {{StateTransferManagerImpl}} can take a long time to do so. In particular, because of {{ISPN-5507}}, {{TransactionTable}} can block for {{cacheStopTimeout}} if there are remote transactions in progress, even though the cache can no longer process remote commands.
We should give {{StateTransferManagerImpl.stop()}} a priority of {{0}}, so that the {{CacheTopologyControlCommand(LEAVE)}} comand is sent as soon as possible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ISPN-6664) JGroupsTransport.invokeRemotelyAsync with a filter returns null on timeout
by Brad Maxwell (JIRA)
Brad Maxwell created ISPN-6664:
----------------------------------
Summary: JGroupsTransport.invokeRemotelyAsync with a filter returns null on timeout
Key: ISPN-6664
URL: https://issues.jboss.org/browse/ISPN-6664
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.2.0.Final, 9.0.0.Final
Reporter: Brad Maxwell
Assignee: Dan Berindei
Fix For: 8.2.1.Final, 9.0.0.Alpha1, 8.1.4.Final, 9.0.0.Final
{{JGroupsTransport.invokeRemotelyAsync()}} has a {{ResponseFilter}} parameter that was traditionally used only with {{ResponseMode.GET_FIRST}}, for remote get commands. In that particular case, returning a {{null}} when some of the nodes timed out and other nodes returned invalid responses (i.e. {{null}}) was acceptable.
Since ISPN-4979, {{JGroupsTransport.invokeRemotelyAsync()}} is also used by {{ClusterTopologyManagerImpl}}, with {{ResponseMode.GET_ALL}}. Here, however, returning a {{null}} instead of throwing a {{TimeoutException}} is not acceptable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ISPN-6663) ClusterTopologyManagerImpl join during cluster status recovery
by Brad Maxwell (JIRA)
Brad Maxwell created ISPN-6663:
----------------------------------
Summary: ClusterTopologyManagerImpl join during cluster status recovery
Key: ISPN-6663
URL: https://issues.jboss.org/browse/ISPN-6663
Project: Infinispan
Issue Type: Bug
Affects Versions: 8.1.3.Final
Reporter: Brad Maxwell
Assignee: Dan Berindei
Fix For: 8.2.0.CR1, 8.1.4.Final
If the joiner has the correct view id, but the current status is
RECOVERING_CLUSTER, we should wait for the cluster status recovery to
finish before adding the new member.
We are currently not doing that, so the new member could be erased by the status recovery process that's in progress. This can happen if the coordinator joiner already had been a member of the JGroups cluster for some time, and there's no view change when they actually start their caches (exactly the scenario in {{ConcurrentStartTest}}).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (ISPN-3368) Quickstart names in the POM files are not consistent and often are not clear
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-3368?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed ISPN-3368.
-------------------------------------
Fix Version/s: 9.0.0.Alpha3
9.0.0.Final
Resolution: Done
> Quickstart names in the POM files are not consistent and often are not clear
> ----------------------------------------------------------------------------
>
> Key: ISPN-3368
> URL: https://issues.jboss.org/browse/ISPN-3368
> Project: Infinispan
> Issue Type: Bug
> Components: Demos and Tutorials
> Reporter: Sande Gilda
> Assignee: Sebastian Łaskawiec
> Priority: Minor
> Fix For: 9.0.0.Alpha3, 9.0.0.Final
>
>
> Quickstart names in the pom.xml files are not consistent and often are too generic and not clear which quickstart is building.
> When you run `mvn clean install '-Pdefault,!complex-dependencies'` from the root directory of the quickstarts, it often is not clear which quickstart is compiling. Some start with "JBoss AS Quickstarts" and some do not. Some use the quickstart folder name in the description, some don't.
> As described in the CONTRIBUTING.md file, the <name> in the quickstart pom.xml file should follow the template:
> JBoss <target-product> Quickstart: <quickstart-name> < - optional-subfolder-name> where target-product is the Target Product metadata specified in the README.md file, quickstart-name is the quickstart folder name, and optional-subfolder-name is the name of any nested subfolder containing a pom.xml file.
> JDF-430 addressed the EAP and WFK quickstarts. The root build not displays the following. Note the RichFaces and JDG quickstarts need to be updated.
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] JBoss EAP Quickstart: bean-validation
> [INFO] JBoss EAP Quickstart: bmt
> [INFO] JBoss WFK Quickstart: cdi-add-interceptor-binding
> [INFO] JBoss EAP Quickstart: cdi-alternative
> [INFO] JBoss EAP Quickstart: cdi-decorator
> [INFO] JBoss EAP Quickstart: cdi-interceptors
> [INFO] JBoss EAP Quickstart: cdi-injection
> [INFO] JBoss EAP Quickstart: cdi-portable-extension
> [INFO] JBoss EAP Quickstart: cdi-stereotype
> [INFO] JBoss EAP Quickstart: cdi-veto
> [INFO] JBoss WFK Quickstart: deltaspike-authorization
> [INFO] JBoss WFK Quickstart: deltaspike-beanbuilder
> [INFO] JBoss WFK Quickstart: deltaspike-beanmanagerprovider
> [INFO] JBoss WFK Quickstart: deltaspike-deactivatable
> [INFO] JBoss WFK Quickstart: deltaspike-exception-handling
> [INFO] JBoss WFK Quickstart: deltaspike-helloworld-jms
> [INFO] JBoss WFK Quickstart: deltaspike-partialbean-basic
> [INFO] JBoss WFK Quickstart: deltaspike-partialbean-advanced
> [INFO] JBoss WFK Quickstart: deltaspike-projectstage
> [INFO] JBoss EAP Quickstart: ejb-asynchronous
> [INFO] JBoss EAP Quickstart: ejb-asynchronous - ejb
> [INFO] JBoss EAP Quickstart: ejb-asynchronous - client
> [INFO] JBoss EAP Quickstart: ejb-in-ear
> [INFO] JBoss EAP Quickstart: ejb-in-ear - ejb
> [INFO] JBoss EAP Quickstart: ejb-in-ear - web
> [INFO] JBoss EAP Quickstart: ejb-in-ear - ear
> [INFO] JBoss EAP Quickstart: ejb-in-war
> [INFO] JBoss EAP Quickstart: ejb-remote - server-side
> [INFO] JBoss EAP Quickstart: ejb-remote - client
> [INFO] JBoss EAP Quickstart: ejb-remote
> [INFO] JBoss EAP Quickstart: ejb-security
> [INFO] JBoss EAP Quickstart: ejb-security-plus
> [INFO] JBoss EAP Quickstart: ejb-security-interceptors
> [INFO] JBoss EAP Quickstart: ejb-throws-exception
> [INFO] JBoss EAP Quickstart: ejb-throws-exception - ejb-api
> [INFO] JBoss EAP Quickstart: ejb-throws-exception - ejb
> [INFO] JBoss EAP Quickstart: ejb-throws-exception - web
> [INFO] JBoss EAP Quickstart: ejb-throws-exception - ear
> [INFO] JBoss EAP Quickstart: ejb-multi-server
> [INFO] JBoss EAP Quickstart: ejb-multi-server - app-one
> [INFO] JBoss EAP Quickstart: ejb-multi-server - app-one - ejb
> [INFO] JBoss EAP Quickstart: ejb-multi-server - app-one - ear
> [INFO] JBoss EAP Quickstart: ejb-multi-server - app-two
> [INFO] JBoss EAP Quickstart: ejb-multi-server - app-two - ejb
> [INFO] JBoss EAP Quickstart: ejb-multi-server - app-two - ear
> [INFO] JBoss EAP Quickstart: ejb-multi-server - app-main
> [INFO] JBoss EAP Quickstart: ejb-multi-server - app-main - ejb
> [INFO] JBoss EAP Quickstart: ejb-multi-server - app-main - web
> [INFO] JBoss EAP Quickstart: ejb-multi-server - app-main - ear
> [INFO] JBoss EAP Quickstart: ejb-multi-server - app-web
> [INFO] JBoss EAP Quickstart: ejb-multi-server - client
> [INFO] JBoss EAP Quickstart: greeter
> [INFO] JBoss EAP Quickstart: greeter-spring
> [INFO] JBoss EAP Quickstart: helloworld
> [INFO] JBoss WFK Quickstart: helloworld-errai
> [INFO] JBoss WFK Quickstart: helloworld-gwt
> [INFO] JBoss WFK Quickstart: helloworld-html5
> [INFO] JBoss EAP Quickstart: helloworld-jms
> [INFO] JBoss EAP Quickstart: helloworld-mdb
> [INFO] JBoss EAP Quickstart: helloworld-osgi
> [INFO] JBoss EAP Quickstart: helloworld-rs
> [INFO] JBoss EAP Quickstart: helloworld-singleton
> [INFO] JBoss EAP Quickstart: helloworld-ws
> [INFO] JBoss EAP Quickstart: hibernate3
> [INFO] JBoss EAP Quickstart: hibernate4
> [INFO] CarMart Single Node (No Cluster)
> [INFO] Transactional CarMart
> [INFO] JBoss AS Quickstarts: JBoss Data Grid HelloWorld
> [INFO] HotRod Endpoint Example
> [INFO] Memcached Endpoint Example
> [INFO] REST Endpoint Example
> [INFO] JBoss Data Grid Quickstart Parent
> [INFO] JBoss EAP Quickstart: kitchensink
> [INFO] JBoss WFK Quickstart: kitchensink-angularjs
> [INFO] JBoss WFK Quickstart: kitchensink-backbone
> [INFO] JBoss WFK Quickstart: kitchensink-deltaspike
> [INFO] JBoss EAP Quickstart: kitchensink-ear
> [INFO] JBoss EAP Quickstart: kitchensink-ear - ejb
> [INFO] JBoss EAP Quickstart: kitchensink-ear - web
> [INFO] JBoss EAP Quickstart: kitchensink-ear - ear
> [INFO] JBoss WFK Quickstart: kitchensink-html5-mobile
> [INFO] JBoss EAP Quickstart: kitchensink-jsp
> [INFO] JBoss EAP Quickstart: kitchensink-ml
> [INFO] JBoss EAP Quickstart: kitchensink-ml-ear
> [INFO] JBoss EAP Quickstart: kitchensink-ml-ear - ejb
> [INFO] JBoss EAP Quickstart: kitchensink-ml-ear - web
> [INFO] JBoss EAP Quickstart: kitchensink-ml-ear - ear
> [INFO] JBoss EAP Quickstart: kitchensink-spring-asyncrequestmapping
> [INFO] JBoss EAP Quickstart: kitchensink-spring-basic
> [INFO] JBoss EAP Quickstart: kitchensink-spring-controller
> [INFO] JBoss EAP Quickstart: kitchensink-spring-matrixvariables
> [INFO] JBoss EAP Quickstart: kitchensink-spring-springmvctest
> [INFO] JBoss EAP Quickstart: log4j
> [INFO] JBoss EAP Quickstart: logging
> [INFO] JBoss EAP Quickstart: logging-tools
> [INFO] JBoss EAP Quickstart: mail
> [INFO] JBoss EAP Quickstart: numberguess
> [INFO] JBoss EAP Quickstart: payment-cdi-event
> [INFO] JBoss EAP Quickstart: picketlink-authentication-http-basic
> [INFO] JBoss EAP Quickstart: picketlink-authentication-http-digest
> [INFO] JBoss EAP Quickstart: petclinic-spring
> [INFO] JBoss EAP Quickstart: picketlink-authentication-idm-jsf
> [INFO] JBoss EAP Quickstart: picketlink-authentication-idm-multi-tenancy
> [INFO] JBoss EAP Quickstart: picketlink-authentication-jsf
> [INFO] JBoss EAP Quickstart: picketlink-authentication-rs-endpoint
> [INFO] JBoss EAP Quickstart: picketlink-authentication-two-factor
> [INFO] JBoss EAP Quickstart: picketlink-authorization-idm-jpa
> [INFO] JBoss EAP Quickstart: picketlink-authorization-rs-rbac
> [INFO] JBoss WFK Quickstart: picketlink-deltaspike-authorization
> [INFO] JBoss AS Quickstarts: Hello world with JSF front end
> [INFO] JBoss AS Quickstarts: Kitchensink-rf
> [INFO] JBoss AS Quickstarts: RichFaces Bean Validation
> [INFO] JBoss EAP Quickstart: servlet-async
> [INFO] JBoss EAP Quickstart: servlet-filterlistener
> [INFO] JBoss EAP Quickstart: servlet-security
> [INFO] JBoss EAP Quickstart: shopping-cart
> [INFO] JBoss EAP Quickstart: shopping-cart - server
> [INFO] JBoss EAP Quickstart: shopping-cart - client
> [INFO] JBoss WFK Quickstart: shrinkwrap-resolver
> [INFO] JBoss EAP Quickstart: tasks
> [INFO] JBoss EAP Quickstart: tasks-jsf
> [INFO] JBoss EAP Quickstart: tasks-rs
> [INFO] JBoss EAP Quickstart: temperature-converter
> [INFO] JBoss EAP Quickstart: wicket-ear
> [INFO] JBoss EAP Quickstart: wicket-ear - ejb
> [INFO] JBoss EAP Quickstart: wicket-ear - war
> [INFO] JBoss EAP Quickstart: wicket-ear - ear
> [INFO] JBoss EAP Quickstart: wicket-war
> [INFO] JBoss EAP Quickstart: xml-dom4j
> [INFO] JBoss EAP Quickstart: xml-jaxp
> [INFO] JBoss EAP Quickstart: cmt
> [INFO] JBoss EAP Quickstart: jts
> [INFO] JBoss EAP Quickstart: jts - application-component-2
> [INFO] JBoss EAP Quickstart: jts - application-component-1
> [INFO] JBoss EAP Quickstart: jta-crash-rec
> [INFO] JBoss EAP Quickstart: wsat-simple
> [INFO] JBoss EAP Quickstart: wsba-coordinator-completion-simple
> [INFO] JBoss EAP Quickstart: wsba-participant-completion-simple
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months