[JBoss JIRA] (AS7-5699) Exception in thread "KeyAffinityService Thread Pool -- 1" java.lang.ArrayIndexOutOfBoundsException: 1
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-5699:
-----------------------------------
Summary: Exception in thread "KeyAffinityService Thread Pool -- 1" java.lang.ArrayIndexOutOfBoundsException: 1
Key: AS7-5699
URL: https://issues.jboss.org/browse/AS7-5699
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Environment: affects: snapshot
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Fix For: 7.2.0.Alpha1
After ISPN upgrade.
{noformat}
23:20:16,415 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "distributable.war"
23:20:16,424 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) JBAS015012: Started FileSystemDeploymentService for directory /home/smarlow/work/as7/testsuite/integration/clust/target/jbossas-clustering-SYNC-tcp-0/standalone/deployments
23:20:16,767 WARN [org.jgroups.stack.Configurator] (ServerService Thread Pool -- 63) [JGRP00013] TP.discard_incompatible_packets has been deprecated: incompatible packets are discarded anyway
23:20:16,957 INFO [stdout] (ServerService Thread Pool -- 63)
23:20:16,957 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
23:20:16,957 INFO [stdout] (ServerService Thread Pool -- 63) GMS: address=node-0/web, cluster=web, physical address=fccc:0:0:0:0:0:0:1%1:7600
23:20:16,957 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
23:20:17,104 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-5) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
23:20:17,105 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-6) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
23:20:17,106 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-5) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
23:20:17,106 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-6) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
23:20:17,107 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-4) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
23:20:17,108 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-4) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
23:20:17,136 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000078: Starting JGroups Channel
23:20:17,140 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000094: Received new cluster view: [node-1/web|3] [node-1/web, node-0/web]
23:20:17,140 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000079: Cache local address is node-0/web, physical addresses are [fccc:0:0:0:0:0:0:1%1:7600]
23:20:17,141 INFO [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 63) ISPN000128: Infinispan version: Infinispan 'Delirium' 5.2.0.Beta1
23:20:17,164 INFO [org.infinispan.factories.TransactionManagerFactory] (ServerService Thread Pool -- 56) ISPN000161: Using a batchMode transaction manager
23:20:17,164 INFO [org.infinispan.factories.TransactionManagerFactory] (ServerService Thread Pool -- 63) ISPN000161: Using a batchMode transaction manager
23:20:17,274 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 56) ISPN000031: MBeans were successfully registered to the platform MBean server.
23:20:17,274 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 63) ISPN000031: MBeans were successfully registered to the platform MBean server.
23:20:17,394 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 56) JBAS010281: Started default-host/distributable cache from web container
23:20:17,396 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) JBAS010281: Started repl cache from web container
23:20:17,405 INFO [org.jboss.as.clustering] (MSC service thread 1-5) JBAS010238: Number of cluster members: 2
23:20:17,414 INFO [org.jboss.web] (MSC service thread 1-7) JBAS018210: Register web context: /distributable
23:20:17,533 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "distributable.war"
23:20:17,688 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://fccc::1:9990/management
23:20:17,689 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://fccc::1:9990
23:20:17,689 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started in 3445ms - Started 171 of 324 services (152 services are passive or on-demand)
23:54:12,922 ERROR [stderr] (KeyAffinityService Thread Pool -- 1) Exception in thread "KeyAffinityService Thread Pool -- 1" java.lang.ArrayIndexOutOfBoundsException: 1
23:54:12,923 ERROR [stderr] (KeyAffinityService Thread Pool -- 1) at org.infinispan.distribution.ch.DefaultConsistentHash.locatePrimaryOwnerForSegment(DefaultConsistentHash.java:137)
23:54:12,923 ERROR [stderr] (KeyAffinityService Thread Pool -- 1) at org.infinispan.distribution.ch.DefaultConsistentHash.locatePrimaryOwner(DefaultConsistentHash.java:152)
23:54:12,923 ERROR [stderr] (KeyAffinityService Thread Pool -- 1) at org.infinispan.affinity.KeyAffinityServiceImpl.getAddressForKey(KeyAffinityServiceImpl.java:347)
23:54:12,924 ERROR [stderr] (KeyAffinityService Thread Pool -- 1) at org.infinispan.affinity.KeyAffinityServiceImpl.access$700(KeyAffinityServiceImpl.java:59)
23:54:12,924 ERROR [stderr] (KeyAffinityService Thread Pool -- 1) at org.infinispan.affinity.KeyAffinityServiceImpl$KeyGeneratorWorker.generateKeys(KeyAffinityServiceImpl.java:270)
23:54:12,924 ERROR [stderr] (KeyAffinityService Thread Pool -- 1) at org.infinispan.affinity.KeyAffinityServiceImpl$KeyGeneratorWorker.run(KeyAffinityServiceImpl.java:242)
23:54:12,925 ERROR [stderr] (KeyAffinityService Thread Pool -- 1) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
23:54:12,925 ERROR [stderr] (KeyAffinityService Thread Pool -- 1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
23:54:12,925 ERROR [stderr] (KeyAffinityService Thread Pool -- 1) at java.lang.Thread.run(Thread.java:662)
23:54:12,925 ERROR [stderr] (KeyAffinityService Thread Pool -- 1) at org.jboss.threads.JBossThread.run(JBossThread.java:122)
{noformat}
--
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
11 years, 6 months
[JBoss JIRA] (AS7-6044) NullPointerException when dependent module is (re)deployed.
by Corey Puffalt (JIRA)
Corey Puffalt created AS7-6044:
----------------------------------
Summary: NullPointerException when dependent module is (re)deployed.
Key: AS7-6044
URL: https://issues.jboss.org/browse/AS7-6044
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.2.Final (EAP)
Environment: OS:
CentOS 6.2 (64 bit)
Java:
java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
Reporter: Corey Puffalt
I have an .ear containing an ejb-jar with a dependency on a jar file external to the .ear but also deployed to JBoss (both files below are deployed to $JBOSS_HOME/standalone/deployments).
The overall structure looks like this:
{code}
kdmmailservice-ear.ear
|-- META-INF
| |-- application.xml
| `-- MANIFEST.MF
`-- kdmmailservice-service.jar
|-- com
| `-- kdm
| `-- mailservice
| |-- JmsMailService.class
| |-- MailModule.class
| `-- MailProcessor.class
`-- META-INF
|-- beans.xml
|-- ejb-jar.xml
`-- MANIFEST.MF
kdmmailservice-templates.jar
|-- META-INF
| |-- MANIFEST.MF
`-- templates
`-- ...
{code}
The MANIFEST.MF in the ejb-jar above (kdmmailservice-service.jar) indicates its dependency on the kdmmailservice-templates.jar via a Dependencies entry:
{code}
Dependencies: deployment.kdmmailservice-templates.jar
{code}
As long as care is taken to deploy the jar file first, followed by the ear file everything is fine. But I need to be able to re-deploy the dependent jar (kdmmailservice-templates.jar) and when I do so, the ear file is undeployed and remains so due to a NullPointerException:
{code}
08:50:50,640 INFO [org.jboss.as.osgi] (MSC service thread 1-3) JBAS011908: Unregister module: Module "deployment.kdmmailservice-templates.jar:main" from Service Module Loader
08:50:50,641 INFO [org.jboss.as.osgi] (MSC service thread 1-4) JBAS011908: Unregister module: Module "deployment.kdmmailservice-ear.ear.kdmmailservice-rest-1.0.1.war:main" from Service Module Loader
08:50:50,642 INFO [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011908: Unregister module: Module "deployment.kdmmailservice-ear.ear:main" from Service Module Loader
08:50:50,643 INFO [org.jboss.as.osgi] (MSC service thread 1-8) JBAS011908: Unregister module: Module "deployment.kdmmailservice-ear.ear.kdmmailservice-service-1.0.1.jar:main" from Service Module Loader
08:50:50,699 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016009: Stopping weld service for deployment kdmmailservice-ear.ear
08:50:50,713 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment kdmmailservice-templates.jar in 73ms
08:50:50,715 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "kdmmailservice-templates.jar"
08:50:50,718 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit."kdmmailservice-ear.ear".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."kdmmailservice-ear.ear".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "kdmmailservice-ear.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.1.2.Final.jar:7.1.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_04]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_04]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_04]
Caused by: java.lang.NullPointerException
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:43)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.1.2.Final.jar:7.1.2.Final]
... 5 more
08:50:50,726 INFO [org.jboss.as.osgi] (MSC service thread 1-4) JBAS011907: Register module: Module "deployment.kdmmailservice-templates.jar:main" from Service Module Loader
08:50:50,911 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018565: Replaced deployment "kdmmailservice-templates.jar" with deployment "kdmmailservice-templates.jar"
08:50:50,911 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
JBAS014777: Services which failed to start: service jboss.deployment.unit."kdmmailservice-ear.ear".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."kdmmailservice-ear.ear".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "kdmmailservice-ear.ear"
{code}
--
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
11 years, 6 months
[JBoss JIRA] (AS7-5403) CLONE - Adding modcluster via the CLI fails.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5403?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-5403:
---------------------------------------
I'm fine with removing the extra level of configuration if JFC is, although you'll still have to support the old mod-cluster-config=configuration child resource for backwards compatibility.
There is still the problem I mentioned above though re: the child resources under mod-cluster-config=configuration (DynamicLoadProviderDefinition, LoadMetricDefinition, CustomLoadMetricDefinition). If those resources are added after the initial add of the subsystem, and during boot, the result is the change isn't applied to the runtime and the server is put into reload-required. At a minimum we need to get it so if those are added after boot but as part of the same composite op that adds the subsystem, the reload isn't required. We can chat about how to do that. Ideally though some of those could be added at any time and the running service would be updated.
Using a default of 'modcluster' for advertise is ok, but only if you track whether or not the value was actually set in the config. IOW, "undefined" in the model leads to trying to use "modcluster" and disabling advertise if unsuccessful. But any specifically defined value has to be correct or it's a failure.
> CLONE - Adding modcluster via the CLI fails.
> --------------------------------------------
>
> Key: AS7-5403
> URL: https://issues.jboss.org/browse/AS7-5403
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Tom Fonteyne
> Assignee: Joe Wertz
> Fix For: 7.2.0.Alpha1
>
>
> Adding modcluster via the CLI fails.
--
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
11 years, 6 months
[JBoss JIRA] (AS7-5403) CLONE - Adding modcluster via the CLI fails.
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/AS7-5403?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar commented on AS7-5403:
-------------------------------------
@[~brian.stansberry] No, I haven't seen it yet (since Joe didn't follow the Jira process and like the PR, nor does the commit itself reference this Jira...).
I don't like this approach though (though for 7.1.x as workaround why not). By what I have done locally so far, as part of AS7-3623, removing the extra level of configuration and just leveraging GenericSubsystemDescribeHandler which enables you to add properties as parameters -- I like this very much.
I am wondering now though, what is the best approach with requiring advertise. The goal is to provide users with best default configuration so we need to make sure that advertise is on by default. However, that means that users either need to specifi advertise-socket or disable advertise when adding the subsystem. How about: make the socket default to 'modcluster' abd if its defined just go with it, otherwise just disable advertise if its not..
PS: 4 comments above, the advertise-socket should be modcluster, not ajp.
> CLONE - Adding modcluster via the CLI fails.
> --------------------------------------------
>
> Key: AS7-5403
> URL: https://issues.jboss.org/browse/AS7-5403
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Tom Fonteyne
> Assignee: Joe Wertz
> Fix For: 7.2.0.Alpha1
>
>
> Adding modcluster via the CLI fails.
--
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
11 years, 6 months
[JBoss JIRA] (AS7-5833) Missing core queue attributes
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-5833:
--------------------------------
Summary: Missing core queue attributes
Key: AS7-5833
URL: https://issues.jboss.org/browse/AS7-5833
Project: Application Server 7
Issue Type: Bug
Components: JMS
Affects Versions: 7.1.3.Final (EAP)
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 7.2.0.Alpha1
the messaging's subsystem queues does not expose all the HornetQ core queue attributes.
Missing attributes:
* dead-letter-address
* expiry-address
Incorrect attributes:
* temporary is flagged as a read-only attribute but it must still be possible to set it when the queue is created => add it to the add operation parameters (default=false)
--
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
11 years, 6 months
[JBoss JIRA] (AS7-6045) Add file handler back to logging.properties on initial boot
by James Perkins (JIRA)
James Perkins created AS7-6045:
----------------------------------
Summary: Add file handler back to logging.properties on initial boot
Key: AS7-6045
URL: https://issues.jboss.org/browse/AS7-6045
Project: Application Server 7
Issue Type: Enhancement
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
The file handler for the boot.log was removed when the logging subsystem changed to persist the logging.properties file. The default logging.properties should add the server.log configuration so the initial boot logging isn't lost.
--
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
11 years, 6 months
[JBoss JIRA] (AS7-6043) implement java version of JDR
by Jesse Jaggars (JIRA)
Jesse Jaggars created AS7-6043:
----------------------------------
Summary: implement java version of JDR
Key: AS7-6043
URL: https://issues.jboss.org/browse/AS7-6043
Project: Application Server 7
Issue Type: Feature Request
Components: JDR
Reporter: Jesse Jaggars
Assignee: Jesse Jaggars
Implement a pure java version of JDR to avoid the numerous issues encountered during productization.
This should also resolve all the current issues for JDR.
--
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
11 years, 6 months