[JBoss JIRA] (DROOLS-1071) NPE's stacktrace for an MvelConstraint.evaluate() should give a line number from the source DRL file
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1071?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet updated DROOLS-1071:
-------------------------------------
Summary: NPE's stacktrace for an MvelConstraint.evaluate() should give a line number from the source DRL file (was: NPE's stacktracke for an MvelConstraint.evaluate() should give a line number from the source DRL file)
> NPE's stacktrace for an MvelConstraint.evaluate() should give a line number from the source DRL file
> ----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1071
> URL: https://issues.jboss.org/browse/DROOLS-1071
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.3.0.Final, 6.4.0.Beta2
> Environment: JDK: Java 7
> OS: Mac OSX 10.10.2
> IDE: Spring Tool Suite 3.6.4
> Reporter: Ido Flax
> Assignee: Mario Fusco
> Attachments: AbstractPlannerDto.java, activity-scoring.drl, EquipmentEquipmentTypesPlannerDto.java, LabourDayOffPlannerDto.java, OnHandForProduct.java, ProductInventoryTransactionPlannerDto.java, ProductPlannerDto.java, SkillsAndRatesPlannerDto.java, TaskPlannerDto.java, TaskResourceAllocationPlannerDto.java, TaskResourcePlannerDto.java, UserPlannerDto.java
>
>
> The attached code generates an NPE when running optaplanner/drools, but that stacktrace doesn't tell me which DRL line is responsible for it.
> Stacktrace:
> {code:java}
> Caused by: java.lang.NullPointerException: null
> at ConditionEvaluatoreaa3997683d949e28ce6eaf6feca0ced.evaluate(Unknown Source) <================ No source DRL line
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowedCachedLeft(MvelConstraint.java:226)
> at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:111)
> at org.drools.core.phreak.PhreakJoinNode.doLeftInserts(PhreakJoinNode.java:112)
> at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:75)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:369)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:329)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:163)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:120)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274)
> at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:84)
> at org.optaplanner.core.impl.solver.recaller.BestSolutionRecaller.solvingStarted(BestSolutionRecaller.java:70)
> at org.optaplanner.core.impl.solver.DefaultSolver.solvingStarted(DefaultSolver.java:197)
> at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:175)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (DROOLS-1071) NPE's stacktracke for an MvelConstraint.evaluate() should give a line number from the source DRL file
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1071?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet moved PLANNER-541 to DROOLS-1071:
--------------------------------------------------
Project: Drools (was: OptaPlanner)
Key: DROOLS-1071 (was: PLANNER-541)
Issue Type: Enhancement (was: Bug)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: core engine
(was: optaplanner-core)
Steps to Reproduce: (was: DRL:
{code:java}
package com.rdthree.plenty.services.activities.planner;
dialect "java"
import org.optaplanner.core.api.score.buildin.simple.SimpleScoreHolder;
import org.optaplanner.core.api.score.buildin.hardsoft.HardSoftScoreHolder;
import org.joda.time.Interval;
import org.joda.time.DateTime;
import org.apache.commons.lang.time.DateUtils;
import org.optaplanner.core.api.domain.solution.PlanningEntityCollectionProperty;
import org.optaplanner.core.api.domain.solution.PlanningSolution;
import org.optaplanner.core.api.domain.solution.Solution;
import org.optaplanner.core.api.domain.valuerange.ValueRangeProvider;
import org.optaplanner.core.api.score.buildin.hardsoft.HardSoftScore;
import com.rdthree.plenty.config.GeneralPrefs;
import com.rdthree.plenty.services.activities.helpers.dtos.TaskPlannerDto;
import com.rdthree.plenty.services.activities.helpers.dtos.TaskResourceAllocationPlannerDto;
import com.rdthree.plenty.services.activities.helpers.dtos.SkillsAndRatesPlannerDto;
import com.rdthree.plenty.services.activities.helpers.dtos.EquipmentEquipmentTypesPlannerDto;
import com.rdthree.plenty.services.activities.helpers.dtos.ProductPlannerDto;
import com.rdthree.plenty.services.activities.helpers.dtos.LabourDayOffPlannerDto;
import com.rdthree.plenty.services.activities.helpers.dtos.OnHandForProduct;
import com.rdthree.plenty.services.activities.planner.TaskRequirementsMapper;
import com.rdthree.plenty.domain.users.LabourDayOff.ApprovalState;
import com.rdthree.plenty.services.activities.planner.ScheduleState;
global HardSoftScoreHolder scoreHolder;
dialect "java"
dialect "mvel"
// ############################################################################
// Soft constraints
// ############################################################################
// DOC
rule "setAllConflictingToFalseFirst"
salience 100
when
$allocation : TaskResourceAllocationPlannerDto()
then
$allocation.setScheduleState(ScheduleState.SCHEDULING);
$allocation.setLabourDayOffConflict(null);
$allocation.setProductShortage(0);
end
rule "taskDateChangeRule"
when
TaskPlannerDto($taskId : id, $taskStart : interval.getStart().toDate())
TaskRequirementsMapper( taskId == $taskId, $taskReqStartMS : startDate.getTime(), startDate.getTime() != $taskStart.getTime())
then
scoreHolder.addSoftConstraintMatch(kcontext, Math.round(Math.abs($taskReqStartMS - $taskStart.getTime()) / 1000 / 60 / 60) * -100);
end
rule "taskPlanIndexChangeRule"
when
$task1 : TaskPlannerDto($task1Activity : activity, $task1Plan : activity.getPlan(), $task1Start : interval.getStart().toDate())
TaskPlannerDto(!activity.equals($task1Activity), activity.getPlan().equals($task1Plan), $task1Activity.indexInPlan > activity.indexInPlan, interval.getStart().toDate() < $task1Start)
TaskPlannerDto(!activity.equals($task1Activity), activity.getPlan().equals($task1Plan), $task1Activity.indexInPlan < activity.indexInPlan, interval.getStart().toDate() < $task1Start)
then
scoreHolder.addHardConstraintMatch(kcontext, -100000);
end
rule "taskLengthChangeRule"
when
TaskPlannerDto($taskId : id, $taskLength : interval.toPeriod().getDays())
TaskRequirementsMapper( taskId == $taskId, $taskReqLength : length, length!=$taskLength)
then
scoreHolder.addSoftConstraintMatch(kcontext, Math.abs($taskReqLength - $taskLength) * -1000);
end
rule "taskResourceChangeRule"
when
$allocation : TaskResourceAllocationPlannerDto( $taskId : taskId )
$mapper : TaskRequirementsMapper( taskId == $taskId )
TaskRequirement( resourceClass.equals($allocation.getResourceClass()), resourceTypeOrSkill.getId() == $allocation.getResourceTypeId(), originalResource.getId() != $allocation.getResource().getId()) from $mapper.getRequirements()
then
scoreHolder.addSoftConstraintMatch(kcontext, -10);
end
// This rule checks if the allocated resource has already been allocated to the same task
rule "duplicateResourceAllocation"
when
TaskPlannerDto($taskId : id)
TaskResourceAllocationPlannerDto($alloc1Id : id, taskId == $taskId, $alloc1Resource : resource)
TaskResourceAllocationPlannerDto(id != $alloc1Id, taskId == $taskId, resource.getId() == $alloc1Resource.getId())
then
scoreHolder.addHardConstraintMatch(kcontext, -100000);
end
// This rule creates a constraint based on overlap of two tasks which use the
// same labourer at the same time. The constraint is multipled by the size of the overlap in days
rule "TaskLabourerTimeOverlap"
when
$task1 : TaskPlannerDto($task1Interval : interval)
$task1ResourceAllocation : TaskResourceAllocationPlannerDto(taskId == $task1.id, resource instanceof SkillsAndRatesPlannerDto, $task1UserId : resource.getUserId())
$task2 : TaskPlannerDto($task1.id != id, $task1Interval.overlaps(interval))
$task2ResourceAllocation : TaskResourceAllocationPlannerDto(taskId == $task2.id, resource instanceof SkillsAndRatesPlannerDto, resource.getUserId().equals($task1UserId))
then
scoreHolder.addHardConstraintMatch(kcontext, $task1Interval.overlap($task2.getInterval()).toPeriod(org.joda.time.PeriodType.days()).getDays() * -1);
$task1ResourceAllocation.setScheduleState(ScheduleState.CONFLICT);
$task2ResourceAllocation.setScheduleState(ScheduleState.CONFLICT);
$task1.setState(ScheduleState.CONFLICT);
$task2.setState(ScheduleState.CONFLICT);
end
// This rule creates a constraint based on overlap of a task and it's labour days off
// The constraint is multipled by the size of the overlap in days
rule "TaskLabourerDayOffOverlap"
when
$task1 : TaskPlannerDto($taskInterval : interval)
$task1ResourceAllocation : TaskResourceAllocationPlannerDto(taskId == $task1.id, resource instanceof SkillsAndRatesPlannerDto, $task1UserId : resource.getUserId())
$labourDayOff : LabourDayOffPlannerDto(userId == $task1UserId, $taskInterval.contains(new DateTime(date).plusMinutes(15)), state.equals(ApprovalState.APPROVED))
then
scoreHolder.addHardConstraintMatch(kcontext, -1);
$task1ResourceAllocation.setScheduleState(ScheduleState.CONFLICT);
$task1ResourceAllocation.setLabourDayOffConflict($labourDayOff.getDate().toDate());
$task1.setState(ScheduleState.CONFLICT);
end
// This rule creates a constraint based on overlap of two tasks which use the
// same equipment at the same time. The constraint is multipled by the size of the overlap in days
rule "TaskEquipmentTimeOverlap"
when
$task1 : TaskPlannerDto($task1Interval : interval)
$task1ResourceAllocation : TaskResourceAllocationPlannerDto(taskId == $task1.id, resource instanceof EquipmentEquipmentTypesPlannerDto, $task1EquipmentId : resource.getEquipmentId())
$task2 : TaskPlannerDto($task1.id != id, $task1Interval.overlaps(interval))
$task2ResourceAllocation : TaskResourceAllocationPlannerDto(taskId == $task2.id, resource instanceof EquipmentEquipmentTypesPlannerDto, resource.getEquipmentId() == $task1EquipmentId)
then
scoreHolder.addHardConstraintMatch(kcontext, $task1Interval.overlap($task2.getInterval()).toPeriod(org.joda.time.PeriodType.days()).getDays() * -1);
$task1ResourceAllocation.setScheduleState(ScheduleState.CONFLICT);
$task2ResourceAllocation.setScheduleState(ScheduleState.CONFLICT);
$task1.setState(ScheduleState.CONFLICT);
$task2.setState(ScheduleState.CONFLICT);
end
// This rule create a constraint based on product defficiency for a product at a taks's start date
rule "TaskProductShortage"
when
$task : TaskPlannerDto( $taskId : id, $taskNeedsProductBy : interval.getStart().plusDays(0).withTimeAtStartOfDay())
$allocation : TaskResourceAllocationPlannerDto( taskId == $taskId, resource instanceof ProductPlannerDto)
OnHandForProduct(date.compareTo($taskNeedsProductBy) == 0 , productId == $allocation.resource.getId(), $onHandAmount : amount, amount - $allocation.amount <= 0)
then
scoreHolder.addHardConstraintMatch(kcontext, $allocation.getAmount() * -1);
$allocation.setScheduleState(ScheduleState.CONFLICT);
$allocation.setProductShortage($allocation.getAmount());
$task.setState(ScheduleState.CONFLICT);
end
{code}
added domain classes as attachments
)
Affects Version/s: 6.4.0.Beta2
6.3.0.Final
(was: 6.3.0.Final)
(was: 6.4.0.Beta2)
> NPE's stacktracke for an MvelConstraint.evaluate() should give a line number from the source DRL file
> -----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1071
> URL: https://issues.jboss.org/browse/DROOLS-1071
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.4.0.Beta2, 6.3.0.Final
> Environment: JDK: Java 7
> OS: Mac OSX 10.10.2
> IDE: Spring Tool Suite 3.6.4
> Reporter: Ido Flax
> Assignee: Geoffrey De Smet
> Attachments: AbstractPlannerDto.java, activity-scoring.drl, EquipmentEquipmentTypesPlannerDto.java, LabourDayOffPlannerDto.java, OnHandForProduct.java, ProductInventoryTransactionPlannerDto.java, ProductPlannerDto.java, SkillsAndRatesPlannerDto.java, TaskPlannerDto.java, TaskResourceAllocationPlannerDto.java, TaskResourcePlannerDto.java, UserPlannerDto.java
>
>
> The attached code generates an NPE when running optaplanner/drools, but that stacktrace doesn't tell me which DRL line is responsible for it.
> Stacktrace:
> {code:java}
> Caused by: java.lang.NullPointerException: null
> at ConditionEvaluatoreaa3997683d949e28ce6eaf6feca0ced.evaluate(Unknown Source) <================ No source DRL line
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowedCachedLeft(MvelConstraint.java:226)
> at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:111)
> at org.drools.core.phreak.PhreakJoinNode.doLeftInserts(PhreakJoinNode.java:112)
> at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:75)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:369)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:329)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:163)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:120)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274)
> at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.calculateScore(DroolsScoreDirector.java:84)
> at org.optaplanner.core.impl.solver.recaller.BestSolutionRecaller.solvingStarted(BestSolutionRecaller.java:70)
> at org.optaplanner.core.impl.solver.DefaultSolver.solvingStarted(DefaultSolver.java:197)
> at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:175)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (WFLY-6283) CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6283?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6283:
------------------------------------
With [Paul's fix|https://github.com/hibernate/hibernate-orm/pull/1268], I see much better results:
{quote}
1:20:26,870 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service '2lc.jar#second_PU'
11:20:26,873 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0003: Stopped 2lc.jar#second_PU.org.hibernate.cache.internal.StandardQueryCache cache from hibernate container
11:20:26,877 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 63) WFLYCLINF0003: Stopped 2lc.jar#second_PU.org.hibernate.cache.spi.UpdateTimestampsCache cache from hibernate container
11:20:26,880 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 64) WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service '2lc.jar#TEST_PU'
11:20:26,886 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0003: Stopped 2lc.jar#TEST_PU.Employee cache from hibernate container
11:20:26,888 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 65) WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service '2lc.jar#second_PU'
11:20:26,889 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0003: Stopped 2lc.jar#TEST_PU.org.hibernate.cache.internal.StandardQueryCache cache from hibernate container
11:20:26,894 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 64) WFLYCLINF0003: Stopped 2lc.jar#TEST_PU.org.hibernate.cache.spi.UpdateTimestampsCache cache from hibernate container
11:20:26,895 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 63) WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service '2lc.jar#TEST_PU'
11:20:26,912 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment 2lc.jar (runtime-name: 2lc.jar) in 62ms
11:20:27,003 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 2) WFLYDR0002: Content removed from location /home/smarlow/wildfly/wftest/wildfly-10.1.0.Final-SNAPSHOT/standalone/data/content/20/1e0efd81346f221665f2eabc25335eb4283f05/content
11:20:27,003 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0009: Undeployed "2lc.jar" (runtime-name: "2lc.jar")
{quote}
> CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6283
> URL: https://issues.jboss.org/browse/WFLY-6283
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Harold Campbell
> Assignee: Scott Marlow
>
> With second level caching enabled in a persistence unit, my application can only be deployed once without restarting wildfly. Redeployment results in this stacktrace:
> 19:06:48,764 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 87) MSC000001: Failed to start service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": org.jboss.msc.service.StartException in service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:954)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:882)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
> ... 7 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> at org.infinispan.interceptors.InterceptorChain.assertNotAdded(InterceptorChain.java:76)
> at org.infinispan.interceptors.InterceptorChain.addInterceptor(InterceptorChain.java:90)
> at org.infinispan.cache.impl.CacheImpl.addInterceptor(CacheImpl.java:879)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.addInterceptor(AbstractDelegatingAdvancedCache.java:65)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:184)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:133)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.prepareForValidation(BaseTransactionalDataRegion.java:145)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.createAccessDelegate(BaseTransactionalDataRegion.java:130)
> at org.hibernate.cache.infinispan.naturalid.NaturalIdRegionImpl.buildAccessStrategy(NaturalIdRegionImpl.java:50)
> at org.hibernate.internal.SessionFactoryImpl.determineNaturalIdRegionAccessStrategy(SessionFactoryImpl.java:600)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:339)
> at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
> ... 9 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (WFLY-6283) CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6283?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6283:
------------------------------------
I was able to recreate the "IllegalStateException: ISPN000371: Cannot remove cache configuration 'local-query' because it is in use" error by following the above steps on a faster machine (deploy 2lc.jar and then undeploy). I'll try the https://dl.dropboxusercontent.com/u/35343318/wftest.jar wildfly build next.
> CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6283
> URL: https://issues.jboss.org/browse/WFLY-6283
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Harold Campbell
> Assignee: Scott Marlow
>
> With second level caching enabled in a persistence unit, my application can only be deployed once without restarting wildfly. Redeployment results in this stacktrace:
> 19:06:48,764 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 87) MSC000001: Failed to start service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": org.jboss.msc.service.StartException in service jboss.persistenceunit."winthorpe-ear.ear#winthorpedb": javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: winthorpedb] Unable to build Hibernate SessionFactory
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:954)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:882)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
> ... 7 more
> Caused by: org.infinispan.commons.CacheConfigurationException: Detected interceptor of type [org.hibernate.cache.infinispan.access.TxInvalidationInterceptor] being added to the interceptor chain 231985794 more than once!
> at org.infinispan.interceptors.InterceptorChain.assertNotAdded(InterceptorChain.java:76)
> at org.infinispan.interceptors.InterceptorChain.addInterceptor(InterceptorChain.java:90)
> at org.infinispan.cache.impl.CacheImpl.addInterceptor(CacheImpl.java:879)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.addInterceptor(AbstractDelegatingAdvancedCache.java:65)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:184)
> at org.hibernate.cache.infinispan.access.PutFromLoadValidator.<init>(PutFromLoadValidator.java:133)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.prepareForValidation(BaseTransactionalDataRegion.java:145)
> at org.hibernate.cache.infinispan.impl.BaseTransactionalDataRegion.createAccessDelegate(BaseTransactionalDataRegion.java:130)
> at org.hibernate.cache.infinispan.naturalid.NaturalIdRegionImpl.buildAccessStrategy(NaturalIdRegionImpl.java:50)
> at org.hibernate.internal.SessionFactoryImpl.determineNaturalIdRegionAccessStrategy(SessionFactoryImpl.java:600)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:339)
> at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:879)
> ... 9 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (WFCORE-1415) SensitivityClassification for process lifecycle actions
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1415:
----------------------------------------
Summary: SensitivityClassification for process lifecycle actions
Key: WFCORE-1415
URL: https://issues.jboss.org/browse/WFCORE-1415
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management, Security
Reporter: Brian Stansberry
Add a sensitivity classification that will be applied to all operations that affect process lifecycle (start/stop/shutdown/restart/suspend/resume) at the various levels (host, server, server-group, server-config). Make it possible to restrict such operations to Administrator/SuperUser roles.
Before anyone starts work on this, discuss with [~harald.pehl] to ensure there's a plan in place for dealing with any impact on the console.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (WFLY-5990) jboss-web replication-granularity ATTRIBUTE causes IllegalStateException when getting attribute on the session
by Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/WFLY-5990?page=com.atlassian.jira.plugin.... ]
Mathieu Lachance edited comment on WFLY-5990 at 2/26/16 10:01 AM:
------------------------------------------------------------------
Hi [~pferraro], you mean that UNDERTOW-622 has been incorpored in wildfly master and/or there's another pull request I should have a look at ?
was (Author: matlach):
Hi Paul, you mean that UNDERTOW-622 has been incorpored in wildfly master and/or there's another pull request I should have a look at ?
> jboss-web replication-granularity ATTRIBUTE causes IllegalStateException when getting attribute on the session
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5990
> URL: https://issues.jboss.org/browse/WFLY-5990
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Environment: JDK 8u60
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
>
> when using the replication granularity ATTRIBUTE as followed:
> {code}
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_8_0.xsd"
> version="8.0">
> <replication-config>
> <replication-granularity>ATTRIBUTE</replication-granularity>
> </replication-config>
> </jboss-web>
> {code}
> using the following web cache container configuration (standalone-ha.xml of Wildfly 10.0.0.CR5):
> {code}
> <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist">
> <transport lock-timeout="60000"/>
> <distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
> <locking isolation="REPEATABLE_READ"/>
> <transaction mode="BATCH"/>
> </distributed-cache>
> </cache-container>
> {code}
> when getting an attribute over the session (i.e. httpServletRequest.getSession().getAttribute(...)) this will eventually result in:
> {code}
> ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-22) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=38}, status=3} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:394)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:350)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:344)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:405)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:390)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionAttributes.getAttribute(FineSessionAttributes.java:71)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.getAttribute(DistributableSession.java:133)
> at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:123)
> at XXX.XXX.core.filter.DevelopmentFilter.testSerialization(DevelopmentFilter.java:155)
> at XXX.XXX.core.filter.DevelopmentFilter.doDevelopmentFilter(DevelopmentFilter.java:133)
> at XXX.XXX.core.filter.DevelopmentFilter.doFilter(DevelopmentFilter.java:112)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.core.filter.IERenderingFilter.doFilter(IERenderingFilter.java:80)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.core.filter.KeepAliveFilter.doFilter(KeepAliveFilter.java:45)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.core.controller.HttpContextFilter.doFilter(HttpContextFilter.java:39)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.common.workers.HalogenHttpCachingFilter.doFilter(HalogenHttpCachingFilter.java:94)
> at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
> at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.core.filter.StaticContentVersionFilter.doFilter(StaticContentVersionFilter.java:73)
> at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
> at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.core.filter.LogFilter.doFilterInternal(LogFilter.java:182)
> at XXX.XXX.core.filter.LogFilter.doSuppressExceptionsFilterInternal(LogFilter.java:201)
> at XXX.XXX.core.filter.LogFilter.doFilter(LogFilter.java:160)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.common.language.LanguageFilter.invokeFilterChain(LanguageFilter.java:105)
> at XXX.XXX.common.language.LanguageFilter.doFilter(LanguageFilter.java:100)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.datasource.legacy.BindThreadLocalConnectionFilter$1.call(BindThreadLocalConnectionFilter.java:44)
> at XXX.XXX.datasource.legacy.BindThreadLocalConnectionFilter$1.call(BindThreadLocalConnectionFilter.java:41)
> at XXX.XXX.datasource.legacy.ThreadLocalConnectionAwareCallable.call(ThreadLocalConnectionAwareCallable.java:86)
> at XXX.XXX.datasource.legacy.ThreadLocalConnectionAwareCallable.withConnection(ThreadLocalConnectionAwareCallable.java:59)
> at XXX.XXX.datasource.legacy.BindThreadLocalConnectionFilter.doFilter(BindThreadLocalConnectionFilter.java:41)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.core.exception.ExceptionFilter.doSuppressExceptionsFilterInternal(ExceptionFilter.java:153)
> at XXX.XXX.core.exception.ExceptionFilter.doFilter(ExceptionFilter.java:134)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at XXX.XXX.web.request.RequestIdentifierFilter.doFilter(RequestIdentifierFilter.java:44)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:121)
> at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176)
> at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145)
> at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92)
> at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:394)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Does this mean that the replication granularity 'ATTRIBUTE' is no longer supported in Wildfly 10?
> if swapping the cache from "distributed" to "replicated" mode, we're getting instead an earlier NullPointerException:
> {code}
> ERROR [io.undertow.servlet.request] (default task-2) UT015012: Failed to generate error page /XXXX/error.jsp for original exception: null. Generating error page resulted in a 500.: java.lang.RuntimeException: org.apache.jasper.JasperException: javax.servlet.ServletException: java.lang.NullPointerException
> at io.undertow.servlet.spec.HttpServletResponseImpl.doErrorDispatch(HttpServletResponseImpl.java:156)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.jasper.JasperException: javax.servlet.ServletException: java.lang.NullPointerException
> at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:581)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:456)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:402)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:346)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:81)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:265)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:200)
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:453)
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:378)
> at io.undertow.servlet.spec.HttpServletResponseImpl.doErrorDispatch(HttpServletResponseImpl.java:154)
> ... 9 more
> Caused by: javax.servlet.ServletException: java.lang.NullPointerException
> at org.apache.jsp.error_jsp._jspService(error_jsp.java:102)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> ... 25 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.interceptors.base.BaseStateTransferInterceptor.visitGetKeysInGroupCommand(BaseStateTransferInterceptor.java:50)
> at org.infinispan.commands.remote.GetKeysInGroupCommand.acceptVisitor(GetKeysInGroupCommand.java:95)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeysInGroupCommand(AbstractVisitor.java:178)
> at org.infinispan.commands.remote.GetKeysInGroupCommand.acceptVisitor(GetKeysInGroupCommand.java:95)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.internalGetGroup(CacheImpl.java:490)
> at org.infinispan.cache.impl.CacheImpl.getGroup(CacheImpl.java:483)
> at org.infinispan.cache.impl.CacheImpl.getGroup(CacheImpl.java:478)
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.getGroup(AbstractDelegatingAdvancedCache.java:227)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionAttributesFactory.createValue(FineSessionAttributesFactory.java:73)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionAttributesFactory.createValue(FineSessionAttributesFactory.java:45)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.createValue(InfinispanSessionFactory.java:55)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.createValue(InfinispanSessionFactory.java:40)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.createSession(InfinispanSessionManager.java:255)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.createSession(DistributableSessionManager.java:107)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:741)
> at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370)
> at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:375)
> at org.apache.jasper.runtime.PageContextImpl.initialize(PageContextImpl.java:137)
> at org.apache.jasper.runtime.JspFactoryImpl.internalGetPageContext(JspFactoryImpl.java:109)
> at org.apache.jasper.runtime.JspFactoryImpl.getPageContext(JspFactoryImpl.java:60)
> at org.apache.jsp.error_jsp._jspService(error_jsp.java:80)
> ... 28 more
> {code}
> It the later, it looks like, in the command interceptor, the cache distribution manager is null, which kind of 'make sense' since we are no longer a distributed cache, but a replicated cache. Does it means that session replication is no longer supported and instead only session distribution is? In my case either way is fine, I'll just crank up the number of owner if only distribution is supported.
> Though, in my company usecase, session replication granularity 'attribute' is definitly required to migrate our application to Wildfly 10.
> I know there's still some open jira ticket to complement the Wildfly 10 documentation, but could you provide any additional insight if I've miss anything.
> Thanks,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (WFLY-5795) HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
by Michal Sudra (JIRA)
[ https://issues.jboss.org/browse/WFLY-5795?page=com.atlassian.jira.plugin.... ]
Michal Sudra edited comment on WFLY-5795 at 2/26/16 9:35 AM:
-------------------------------------------------------------
I've re-run the tests on my environment with the latest WildFly 10.0.0.Final release and problem still appears.
{code:java}
Sent message: This is text message 0
Sent message: This is text message 1
Sent message: This is text message 2
Sent message: This is text message 3
Sent message: This is text message 4
Sent message: This is text message 5
Sent message: This is text message 6
Sent message: This is text message 7
Sent message: This is text message 8
Sent message: This is text message 9
0 Recieved message: This is text message 0 from node 0 from jms/topic/ClusterStateTopic
1 Recieved message: This is text message 2 from node 0 from jms/topic/ClusterStateTopic
2 Recieved message: This is text message 4 from node 0 from jms/topic/ClusterStateTopic
3 Recieved message: This is text message 6 from node 0 from jms/topic/ClusterStateTopic
4 Recieved message: This is text message 8 from node 0 from jms/topic/ClusterStateTopic
5 error receiving message from node 0
6 error receiving message from node 0
7 error receiving message from node 0
8 error receiving message from node 0
9 error receiving message from node 0
0 Recieved message: This is text message 0 from node 1 from jms/topic/ClusterStateTopic
1 Recieved message: This is text message 1 from node 1 from jms/topic/ClusterStateTopic
2 Recieved message: This is text message 2 from node 1 from jms/topic/ClusterStateTopic
3 Recieved message: This is text message 3 from node 1 from jms/topic/ClusterStateTopic
4 Recieved message: This is text message 4 from node 1 from jms/topic/ClusterStateTopic
5 Recieved message: This is text message 5 from node 1 from jms/topic/ClusterStateTopic
6 Recieved message: This is text message 6 from node 1 from jms/topic/ClusterStateTopic
7 Recieved message: This is text message 7 from node 1 from jms/topic/ClusterStateTopic
8 Recieved message: This is text message 8 from node 1 from jms/topic/ClusterStateTopic
9 Recieved message: This is text message 9 from node 1 from jms/topic/ClusterStateTopic
example complete
#####################
### SUCCESS! ###
#####################
{code}
I've attached the output log files for both WildFly instances of my domain - master and slave.
It seems that for every message that was not delivered to receiver on node 0, there is an warning entry in the slave.log file with message:
{code:java}
[org.apache.activemq.artemis.core.server] (default I/O-1) AMQ222196: Could not find binding with id=51 on routeFromCluster for message=ServerMessage[messageID=88,durable=true,userID=e28f3fe3-dc93-11e5-a855-d7d7c9cb596b,priority=4, bodySize=392, timestamp=Fri Feb 26 14:19:02 UTC 2016,expiration=0, durable=true, address=jms.topic.ClusterStateTopic,properties=TypedProperties[__AMQ_CID=e08f2a14-dc93-11e5-a855-d7d7c9cb596b]]@88941223 binding = BindingsImpl [name=jms.topic.ClusterStateTopic]
{code}
Could you provide some more info how did you test it on your side? Did you run 2 standalone instances of WildFly? Could you provide me your configuration of the colocated replication?
was (Author: msudra):
I've re-run the tests on my environment with the latest WildFly 10.0.0.Final release and problem still appears.
{code:java}
Sent message: This is text message 0
Sent message: This is text message 1
Sent message: This is text message 2
Sent message: This is text message 3
Sent message: This is text message 4
Sent message: This is text message 5
Sent message: This is text message 6
Sent message: This is text message 7
Sent message: This is text message 8
Sent message: This is text message 9
0 Recieved message: This is text message 0 from node 0 from jms/topic/ClusterStateTopic
1 Recieved message: This is text message 2 from node 0 from jms/topic/ClusterStateTopic
2 Recieved message: This is text message 4 from node 0 from jms/topic/ClusterStateTopic
3 Recieved message: This is text message 6 from node 0 from jms/topic/ClusterStateTopic
4 Recieved message: This is text message 8 from node 0 from jms/topic/ClusterStateTopic
5 error receiving message from node 0
6 error receiving message from node 0
7 error receiving message from node 0
8 error receiving message from node 0
9 error receiving message from node 0
0 Recieved message: This is text message 0 from node 1 from jms/topic/ClusterStateTopic
1 Recieved message: This is text message 1 from node 1 from jms/topic/ClusterStateTopic
2 Recieved message: This is text message 2 from node 1 from jms/topic/ClusterStateTopic
3 Recieved message: This is text message 3 from node 1 from jms/topic/ClusterStateTopic
4 Recieved message: This is text message 4 from node 1 from jms/topic/ClusterStateTopic
5 Recieved message: This is text message 5 from node 1 from jms/topic/ClusterStateTopic
6 Recieved message: This is text message 6 from node 1 from jms/topic/ClusterStateTopic
7 Recieved message: This is text message 7 from node 1 from jms/topic/ClusterStateTopic
8 Recieved message: This is text message 8 from node 1 from jms/topic/ClusterStateTopic
9 Recieved message: This is text message 9 from node 1 from jms/topic/ClusterStateTopic
example complete
#####################
### SUCCESS! ###
#####################
{code}
I've attached the output log files for both WildFly instances of my domain - master and slave.
It seems that for every message that was not delivered to receiver on node 0, there is an warning entry in the slave.log file with message:
{code:java}
[org.apache.activemq.artemis.core.server] (default I/O-1) AMQ222196: Could not find binding with id=51 on routeFromCluster for message=ServerMessage[messageID=88,durable=true,userID=e28f3fe3-dc93-11e5-a855-d7d7c9cb596b,priority=4, bodySize=392, timestamp=Fri Feb 26 14:19:02 UTC 2016,expiration=0, durable=true, address=jms.topic.ClusterStateTopic,properties=TypedProperties[__AMQ_CID=e08f2a14-dc93-11e5-a855-d7d7c9cb596b]]@88941223 binding = BindingsImpl [name=jms.topic.ClusterStateTopic]
{code}
> HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5795
> URL: https://issues.jboss.org/browse/WFLY-5795
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Environment: 2 node symmetrical colocated life backup cluster (domain mode). Configuration (domain.xml, host.xml) provided as attachment.
> Reporter: Michal Sudra
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 10.0.0.Final
>
> Attachments: ClusteredTopicTest.java, domain.xml, host-slave.xml, host.xml, master.log, slave.log
>
>
> Test Client is producing 10 messages on topic on node 1 and 2 consumers connected to node 1 and the other to node 2 are then consuming the messages.
> Expectation: Every consumer receives 10 Messages.
> Result of test: Consumer connected to node 1 is only getting every second message. Consumer connected to node 2 is receiving all 10 messages:
> Output of test program:
> Sent message: This is text message 0
> Sent message: This is text message 1
> Sent message: This is text message 2
> Sent message: This is text message 3
> Sent message: This is text message 4
> Sent message: This is text message 5
> Sent message: This is text message 6
> Sent message: This is text message 7
> Sent message: This is text message 8
> Sent message: This is text message 9
> 0 Recieved message: This is text message 0 from node 0 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 2 from node 0 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 4 from node 0 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 6 from node 0 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 8 from node 0 from java:/jms/topic/ClusterStateTopic
> 5 error receiving message from node 0
> 6 error receiving message from node 0
> 7 error receiving message from node 0
> 8 error receiving message from node 0
> 9 error receiving message from node 0
> 0 Recieved message: This is text message 0 from node 1 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 1 from node 1 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 2 from node 1 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 3 from node 1 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 4 from node 1 from java:/jms/topic/ClusterStateTopic
> 5 Recieved message: This is text message 5 from node 1 from java:/jms/topic/ClusterStateTopic
> 6 Recieved message: This is text message 6 from node 1 from java:/jms/topic/ClusterStateTopic
> 7 Recieved message: This is text message 7 from node 1 from java:/jms/topic/ClusterStateTopic
> 8 Recieved message: This is text message 8 from node 1 from java:/jms/topic/ClusterStateTopic
> 9 Recieved message: This is text message 9 from node 1 from java:/jms/topic/ClusterStateTopic
> The test program is added and the 2 node names are given as parameters for main.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (WFLY-5857) HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but start is not called in Node1 again after Node1 is selected Master again
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5857?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-5857:
------------------------------------
"Is there any Description of methods at all?"
Which methods?
"Despite of Examples in GitHub -some background was-is absent."
I will be posting documentation of singleton services in WildFly 10 today.
"Will be old solutions supported in new versions of WF?"
Which solutions? The singleton service API is public API, and thus will evolve in a manner that maintains backwards compatibility.
> HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but start is not called in Node1 again after Node1 is selected Master again
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5857
> URL: https://issues.jboss.org/browse/WFLY-5857
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.1.Final
> Environment: Wildfly-9.0.1.Final. Full HA Configuration. Cluster Full Ha
> Reporter: Serg Jakean19019
> Assignee: Paul Ferraro
>
> HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but Start is not called in Node1 again after Node1 is selected Master again.
> If Node2 ist started again, than Start is called in Node1 again.
> This Solution worked in 8.2.0.Final and was taken from GitHub
> Part of Log after Stop in Singletone:
> 2015-12-16 10:25:39,832 WARN [org.wildfly.clustering.server] (remote-thread--p8-t5) WFLYCLSV0007: Just reached required quorum of 1 for jboss.quickstart.ha.singleton.default service. If this cluster loses another member, no node will be chosen to provide this service.
> 2015-12-16 10:25:39,832 INFO [org.wildfly.clustering.server] (remote-thread--p8-t5) WFLYCLSV0003: DevNode1 elected as the singleton provider of the jboss.quickstart.ha.singleton.default service
> 2015-12-16 10:25:40,410 WARN [org.hornetq.core.client] (Thread-514 (HornetQ-client-global-threads-816000930)) HQ212037: Connection failure has been detected: HQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
> 2015-12-16 10:25:40,424 WARN [org.hornetq.core.client] (Thread-515 (HornetQ-client-global-threads-816000930)) HQ212037: Connection failure has been detected: HQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
> 2015-12-16 10:25:40,442 INFO [org.hornetq.core.server] (Thread-16 (HornetQ-server-HornetQServerImpl::serverUUID=5f62a17c-a33d-11e5-b968-cda4b2119720-1601129088)) HQ221029: stopped bridge sf.my-cluster.b27b8fc6-a33e-11e5-84b8-b7bbc6dfe24c
> 2015-12-16 10:25:40,495 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel server: [Node1|2] (1) [DevNode1]
> 2015-12-16 10:25:40,496 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel ejb: [Node1|2] (1) [DevNode1]
> 2015-12-16 10:25:40,497 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel hibernate: [DevNode1|2] (1) [DevNode1]
> 2015-12-16 10:25:57,010 WARNING [org.jgroups.protocols.UDP] (INT-1,hq-cluster,DevNode1) JGRP000012: discarded message from different cluster ee (our cluster is hq-cluster). Sender was DevNode1 (received 38 identical messages from DevNode1 in the last 63946 ms)
> 2015-12-16 10:26:30,810 WARNING [org.jgroups.protocols.UDP] (Incoming-13,ee,DevNode1) JGRP000012: discarded message from different cluster hq-cluster (our cluster is ee). Sender was DevNode1 (received 80 identical messages from DevNode1 in the last 60008 ms)
> This issue also in:
> https://developer.jboss.org/thread/266831
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (WFLY-5795) HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
by Michal Sudra (JIRA)
[ https://issues.jboss.org/browse/WFLY-5795?page=com.atlassian.jira.plugin.... ]
Michal Sudra edited comment on WFLY-5795 at 2/26/16 9:28 AM:
-------------------------------------------------------------
I've re-run the tests on my environment with the latest WildFly 10.0.0.Final release and problem still appears.
{code:java}
Sent message: This is text message 0
Sent message: This is text message 1
Sent message: This is text message 2
Sent message: This is text message 3
Sent message: This is text message 4
Sent message: This is text message 5
Sent message: This is text message 6
Sent message: This is text message 7
Sent message: This is text message 8
Sent message: This is text message 9
0 Recieved message: This is text message 0 from node 0 from jms/topic/ClusterStateTopic
1 Recieved message: This is text message 2 from node 0 from jms/topic/ClusterStateTopic
2 Recieved message: This is text message 4 from node 0 from jms/topic/ClusterStateTopic
3 Recieved message: This is text message 6 from node 0 from jms/topic/ClusterStateTopic
4 Recieved message: This is text message 8 from node 0 from jms/topic/ClusterStateTopic
5 error receiving message from node 0
6 error receiving message from node 0
7 error receiving message from node 0
8 error receiving message from node 0
9 error receiving message from node 0
0 Recieved message: This is text message 0 from node 1 from jms/topic/ClusterStateTopic
1 Recieved message: This is text message 1 from node 1 from jms/topic/ClusterStateTopic
2 Recieved message: This is text message 2 from node 1 from jms/topic/ClusterStateTopic
3 Recieved message: This is text message 3 from node 1 from jms/topic/ClusterStateTopic
4 Recieved message: This is text message 4 from node 1 from jms/topic/ClusterStateTopic
5 Recieved message: This is text message 5 from node 1 from jms/topic/ClusterStateTopic
6 Recieved message: This is text message 6 from node 1 from jms/topic/ClusterStateTopic
7 Recieved message: This is text message 7 from node 1 from jms/topic/ClusterStateTopic
8 Recieved message: This is text message 8 from node 1 from jms/topic/ClusterStateTopic
9 Recieved message: This is text message 9 from node 1 from jms/topic/ClusterStateTopic
example complete
#####################
### SUCCESS! ###
#####################
{code}
I've attached the output log files for both WildFly instances of my domain - master and slave.
It seems that for every message that was not delivered to receiver on node 0, there is an warning entry in the slave.log file with message:
{code:java}
[org.apache.activemq.artemis.core.server] (default I/O-1) AMQ222196: Could not find binding with id=51 on routeFromCluster for message=ServerMessage[messageID=88,durable=true,userID=e28f3fe3-dc93-11e5-a855-d7d7c9cb596b,priority=4, bodySize=392, timestamp=Fri Feb 26 14:19:02 UTC 2016,expiration=0, durable=true, address=jms.topic.ClusterStateTopic,properties=TypedProperties[__AMQ_CID=e08f2a14-dc93-11e5-a855-d7d7c9cb596b]]@88941223 binding = BindingsImpl [name=jms.topic.ClusterStateTopic]
{code}
was (Author: msudra):
I've re-run the tests on my environment with the latest WildFly 10.0.0.Final release and problem still appears.
{code:java}
Sent message: This is text message 0
Sent message: This is text message 1
Sent message: This is text message 2
Sent message: This is text message 3
Sent message: This is text message 4
Sent message: This is text message 5
Sent message: This is text message 6
Sent message: This is text message 7
Sent message: This is text message 8
Sent message: This is text message 9
0 Recieved message: This is text message 0 from node 0 from jms/topic/ClusterStateTopic
1 Recieved message: This is text message 2 from node 0 from jms/topic/ClusterStateTopic
2 Recieved message: This is text message 4 from node 0 from jms/topic/ClusterStateTopic
3 Recieved message: This is text message 6 from node 0 from jms/topic/ClusterStateTopic
4 Recieved message: This is text message 8 from node 0 from jms/topic/ClusterStateTopic
5 error receiving message from node 0
6 error receiving message from node 0
7 error receiving message from node 0
8 error receiving message from node 0
9 error receiving message from node 0
0 Recieved message: This is text message 0 from node 1 from jms/topic/ClusterStateTopic
1 Recieved message: This is text message 1 from node 1 from jms/topic/ClusterStateTopic
2 Recieved message: This is text message 2 from node 1 from jms/topic/ClusterStateTopic
3 Recieved message: This is text message 3 from node 1 from jms/topic/ClusterStateTopic
4 Recieved message: This is text message 4 from node 1 from jms/topic/ClusterStateTopic
5 Recieved message: This is text message 5 from node 1 from jms/topic/ClusterStateTopic
6 Recieved message: This is text message 6 from node 1 from jms/topic/ClusterStateTopic
7 Recieved message: This is text message 7 from node 1 from jms/topic/ClusterStateTopic
8 Recieved message: This is text message 8 from node 1 from jms/topic/ClusterStateTopic
9 Recieved message: This is text message 9 from node 1 from jms/topic/ClusterStateTopic
example complete
#####################
### SUCCESS! ###
#####################
{code}
I've attached the output log files for both WildFly instances of my domain - master and slave.
> HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5795
> URL: https://issues.jboss.org/browse/WFLY-5795
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Environment: 2 node symmetrical colocated life backup cluster (domain mode). Configuration (domain.xml, host.xml) provided as attachment.
> Reporter: Michal Sudra
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 10.0.0.Final
>
> Attachments: ClusteredTopicTest.java, domain.xml, host-slave.xml, host.xml, master.log, slave.log
>
>
> Test Client is producing 10 messages on topic on node 1 and 2 consumers connected to node 1 and the other to node 2 are then consuming the messages.
> Expectation: Every consumer receives 10 Messages.
> Result of test: Consumer connected to node 1 is only getting every second message. Consumer connected to node 2 is receiving all 10 messages:
> Output of test program:
> Sent message: This is text message 0
> Sent message: This is text message 1
> Sent message: This is text message 2
> Sent message: This is text message 3
> Sent message: This is text message 4
> Sent message: This is text message 5
> Sent message: This is text message 6
> Sent message: This is text message 7
> Sent message: This is text message 8
> Sent message: This is text message 9
> 0 Recieved message: This is text message 0 from node 0 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 2 from node 0 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 4 from node 0 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 6 from node 0 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 8 from node 0 from java:/jms/topic/ClusterStateTopic
> 5 error receiving message from node 0
> 6 error receiving message from node 0
> 7 error receiving message from node 0
> 8 error receiving message from node 0
> 9 error receiving message from node 0
> 0 Recieved message: This is text message 0 from node 1 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 1 from node 1 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 2 from node 1 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 3 from node 1 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 4 from node 1 from java:/jms/topic/ClusterStateTopic
> 5 Recieved message: This is text message 5 from node 1 from java:/jms/topic/ClusterStateTopic
> 6 Recieved message: This is text message 6 from node 1 from java:/jms/topic/ClusterStateTopic
> 7 Recieved message: This is text message 7 from node 1 from java:/jms/topic/ClusterStateTopic
> 8 Recieved message: This is text message 8 from node 1 from java:/jms/topic/ClusterStateTopic
> 9 Recieved message: This is text message 9 from node 1 from java:/jms/topic/ClusterStateTopic
> The test program is added and the 2 node names are given as parameters for main.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0
[JBoss JIRA] (WFLY-6293) <ejb-name> tag in <interceptor-binding> should support regular expression usages
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-6293?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-6293:
-----------------------------------
Note that this usage isn't what is traditionally defined as "regular expressions"; more like advanced wildcards. Regular expressions would be incompatible with the raw "*" usage. But you could use traditional shell-style wildcard syntax: http://tldp.org/LDP/GNU-Linux-Tools-Summary/html/x11655.htm
Such wildcard syntax can easily be transformed into a regular expression using substitution, and then applied to matching EJB names thusly.
> <ejb-name> tag in <interceptor-binding> should support regular expression usages
> --------------------------------------------------------------------------------
>
> Key: WFLY-6293
> URL: https://issues.jboss.org/browse/WFLY-6293
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Stuart Douglas
>
> From the ejb specification the only possibility is to use the full EJB name or the wildcard "*".
> * If the application is too large with many hundreds or thousand ejbs then it is complex to define the interceptor individually for number of beans having a common name pattern.
> The <ejb-name> element in <interceptor-binding> should support regular expression usages. Like following via "ejb-jar.xml" or using "jboss-ejb3.xml":
> {code}
> <interceptor-binding>
> <ejb-name>Intercepted*Bean</ejb-name>
> <interceptor-class>interceptors.InterceptorOne</interceptor-class>
> </interceptor-binding>
> <interceptor-binding>
> <ejb-name>[AB]*Bean</ejb-name>
> <interceptor-class>interceptors.InterceptorOne</interceptor-class>
> </interceptor-binding>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
- 1
- 0