[JBoss JIRA] (AS7-4869) TypeConverter does not properly convert ExpressionValue
by Emanuel Muckenhuber (JIRA)
Emanuel Muckenhuber created AS7-4869:
----------------------------------------
Summary: TypeConverter does not properly convert ExpressionValue
Key: AS7-4869
URL: https://issues.jboss.org/browse/AS7-4869
Project: Application Server 7
Issue Type: Bug
Components: Domain Management, JMX
Affects Versions: 7.1.0.Final
Reporter: Emanuel Muckenhuber
Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
Executing the following code results in an IAE:
{code}
String[] offsetPath = {"jboss.as:socket-binding-group=standard-sockets","port-offset"};
MBeanServer server = ManagementFactory.getPlatformMBeanServer();
ObjectName name;
try {
name = new ObjectName(offsetPath[0]);
Object offset = server.getAttribute(name, offsetPath[1]);
} catch (Exception e){
e.printStackTrace();
}
{code}
{noformat}
ExpressionValue(ModelValue).asInt() line: 58
ModelNode.asInt() line: 226
TypeConverter$IntegerTypeConverter.fromModelNode(ModelNode) line: 303
TypeConverter.fromModelNode(ModelNode, ModelNode) line: 83
ModelControllerMBeanHelper.getAttribute(RootResourceHack$ResourceAndRegistration, PathAddress, ObjectName, String) line: 220
ModelControllerMBeanHelper.getAttribute(ObjectName, String) line: 181
ModelControllerMBeanServerPlugin.getAttribute(ObjectName, String) line: 69
PluggableMBeanServerImpl.getAttribute(ObjectName, String) line: 154
TestSingleton.<init>() line: 39
NativeConstructorAccessorImpl.newInstance0(Constructor, Object[]) line: not available [native method]
NativeConstructorAccessorImpl.newInstance(Object[]) line: 39
DelegatingConstructorAccessorImpl.newInstance(Object[]) line: 27
Constructor<T>.newInstance(Object...) line: 513
ConstructedValue<T>.getValue() line: 61
ValueManagedReferenceFactory.getReference() line: 49
ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(InterceptorContext) line: 90
InterceptorContext.proceed() line: 288
WeavedInterceptor.processInvocation(InterceptorContext) line: 53
InterceptorContext.proceed() line: 288
NamespaceContextInterceptor.processInvocation(InterceptorContext) line: 50
InterceptorContext.proceed() line: 288
EjbBMTInterceptor.handleInvocation(InterceptorContext) line: 105
EjbBMTInterceptor(BMTInterceptor).processInvocation(InterceptorContext) line: 56
InterceptorContext.proceed() line: 288
CurrentInvocationContextInterceptor.processInvocation(InterceptorContext) line: 41
InterceptorContext.proceed() line: 288
TCCLInterceptor.processInvocation(InterceptorContext) line: 45
InterceptorContext.proceed() line: 288
ChainedInterceptor.processInvocation(InterceptorContext) line: 61
SingletonComponent(BasicComponent).constructComponentInstance(ManagedReference, boolean, InterceptorFactoryContext) line: 161
SingletonComponent(BasicComponent).createInstance() line: 85
SingletonComponent.getComponentInstance() line: 116
SingletonComponent.start() line: 130
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JBRULES-3525) Planner causes score corruption (and doesn't even detect it)
by Lukáš Petrovický (JIRA)
Lukáš Petrovický created JBRULES-3525:
-----------------------------------------
Summary: Planner causes score corruption (and doesn't even detect it)
Key: JBRULES-3525
URL: https://issues.jboss.org/browse/JBRULES-3525
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-planner
Affects Versions: 5.5.0.Beta1
Reporter: Lukáš Petrovický
Assignee: Geoffrey De Smet
Attachments: runtime.log
Using incremental score calculation, I've been having weird problems where solutions have outdated scores. These scores are "fixed" when I explicitly call my score calculator on them. After tons of debugging, I was able to produce the attached simplified log file. I will explain it here:
ItineraryAssignment is a planning entity. Lines as these should be clear:
21:28:33.377 [main] DEBUG o.d.p.e.ras2012.ScoreCalculator - Inserting entity: ItineraryAssignment [train=A1, route=0]
21:28:33.377 [main] DEBUG o.d.p.e.ras2012.ScoreCalculator - Inserting entity: ItineraryAssignment [train=A1, route=0]
Lines like this signify that calculateScore() was called on the calculator:
21:28:33.833 [main] DEBUG o.d.p.e.ras2012.ScoreCalculator - Calculating score.
Lines like this mean that setScore() has been called on a Solution. They will finally demonstrate the problem:
21:28:33.867 [main] DEBUG o.d.p.e.ras2012.ProblemSolution - Setting score -968hard/-3409soft to solution RAS2012Solution ...
What we see in the log file is that after a move is done, score is properly re-calculated and set:
21:28:33.922 [main] DEBUG o.d.p.e.r.move.RouteReassignmentMove - Doing move RouteReassignmentMove [train=A2, 0 -> 256].
21:28:34.215 [main] DEBUG o.d.p.e.ras2012.ScoreCalculator - Removing entity: ItineraryAssignment [train=A2, route=0]
21:28:34.216 [main] DEBUG o.d.p.e.r.model.ItineraryAssignment - Creating new itinerary for ItineraryAssignment [train=A2, route=256].
21:28:34.216 [main] DEBUG o.d.p.e.ras2012.ScoreCalculator - Inserting entity: ItineraryAssignment [train=A2, route=256]
21:28:34.223 [main] DEBUG o.d.p.e.ras2012.ScoreCalculator - Calculating score.
21:28:34.232 [main] DEBUG o.d.p.e.ras2012.ProblemSolution - Setting score -300hard/-1294soft to solution RAS2012Solution ...
However, on the undo move for the very same move, no score calculation takes place, no setScore() takes place and no solution is cloned. Resulting in Solution with outdated score:
21:28:34.232 [main] DEBUG o.d.p.e.r.m.RouteReassignmentUndoMove - Doing move RouteReassignmentUndoMove [train=A2, 256 -> 0].
21:28:34.297 [main] DEBUG o.d.p.e.ras2012.ScoreCalculator - Removing entity: ItineraryAssignment [train=A2, route=256]
21:28:34.299 [main] DEBUG o.d.p.e.r.model.ItineraryAssignment - Creating new itinerary for ItineraryAssignment [train=A2, route=0].
21:28:34.299 [main] DEBUG o.d.p.e.ras2012.ScoreCalculator - Inserting entity: ItineraryAssignment [train=A2, route=0]
21:28:34.305 [main] TRACE o.d.p.c.l.decider.DefaultDecider - Move score (-300hard/-1294soft), accepted (true) for move (RouteReassignmentMove [train=A2, 0 -> 256]).
Which is why the move directly after that (which has been hard-coded to throw exception when the score doesn't match the expected one) throws an exception:
21:28:34.305 [main] DEBUG o.d.p.e.r.move.RouteReassignmentMove - Doing move RouteReassignmentMove [train=A2, 0 -> 274].
Exception in thread "main" java.lang.IllegalStateException: RouteReassignmentMove [train=A2, 0 -> 274]: broken score found. Was -300hard/-1294soft but -968hard/-3409soft expected.
at org.drools.planner.examples.ras2012.move.CommonMove.assertValidScore(CommonMove.java:16)
...
Furthermore, setting environmentMode to TRACE doesn't help here. This goes completely undetected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-4959) CLONE - Hornetq adapter doesn't implement ActivationConfigProperty DeliveryActive
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-4959:
--------------------------------
Summary: CLONE - Hornetq adapter doesn't implement ActivationConfigProperty DeliveryActive
Key: AS7-4959
URL: https://issues.jboss.org/browse/AS7-4959
Project: Application Server 7
Issue Type: Bug
Components: EE, EJB, JMS
Affects Versions: 7.1.1.Final, 7.1.2.Final (EAP)
Environment: Windows 64 bit
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
I get this warning on AS7.1.1 console, seems that ActivationConfigProperty DeliveryActive is not implemented by hornetq-ra, could we please have it as earlier JMS implementation of JMS had it & application that were using it will fail with AS7 now..?
16:04:30,794 WARN [org.jboss.ejb3] (MSC service thread 1-16) JBAS014105: ActivationConfigProperty DeliveryActive will be ignored since it is not allowed by resource adapter: hornetq-ra
Thanks,
Prasad
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-4110) The node name can not set proper via <server name=> attribute
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created AS7-4110:
-------------------------------------
Summary: The node name can not set proper via <server name=> attribute
Key: AS7-4110
URL: https://issues.jboss.org/browse/AS7-4110
Project: Application Server 7
Issue Type: Bug
Components: Clustering, EJB, Remoting, Server, Transactions
Affects Versions: 7.1.0.Final
Reporter: Wolf-Dieter Fink
Assignee: Paul Ferraro
The node name can be set by using '-Djboss.node.name' in standalone mode.
In domain mode this is not possible.
The attribute "name" of the server element should be used for that (for SA and domains host.xml)
But current there is no effect if the client use EJBClient.getUserTransaction( node-name ), client error is "No EJBReceiver available for node name
MyNode".
The management console shows the correct server name set by <server name=>.
Also if the system-properties element is used to set "jboss.node.name" this is not reflected by management console
but if an application use System.getProperty("jboss.node.name") the value of the system-property is returned.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JASSIST-166) Invalid assumption involving "length" variable
by Flávio Brasil (JIRA)
Flávio Brasil created JASSIST-166:
-------------------------------------
Summary: Invalid assumption involving "length" variable
Key: JASSIST-166
URL: https://issues.jboss.org/browse/JASSIST-166
Project: Javassist
Issue Type: Bug
Affects Versions: 3.16.1-GA, 3.15.0-GA
Environment: MacBook Air
Mac OS X Lion 10.7.3 (11D50b)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)
Reporter: Flávio Brasil
Assignee: Shigeru Chiba
Invalid assumption involving "length" variable. Method javassist.compiler.TypeChecker.atExpr(Expr) assumes that the variable length is a method from an array.
The problem is not reproductible with another variables names.
The main class to reproduce the bug is in the field "Steps to reproduce".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JGRP-1449) SEQUENCER race leads to lost messages
by David Hotham (JIRA)
David Hotham created JGRP-1449:
----------------------------------
Summary: SEQUENCER race leads to lost messages
Key: JGRP-1449
URL: https://issues.jboss.org/browse/JGRP-1449
Project: JGroups
Issue Type: Bug
Affects Versions: 3.0.9
Reporter: David Hotham
Assignee: Bela Ban
I'm seeing an issue where SEQUENCER is dropping messages, with logs like this:
2012-04-13 10:05:21.363 [Incoming-1,pisces,CFS-B-pisces-cfs02] ERROR org.jgroups.protocols.SEQUENCER - CFS-B-pisces-cfs02: non-coord; dropping FORWARD request from CFS-A-pisces-cfs03
It looks as though there's some sort of race where:
- a member ("CFS-B-pisces-cfs02") is becoming coordinator, but SEQUENCER hasn't yet seen the view change
- meanwhile some other member ("CFS-A-pisces-cfs03") has been told of the view change, and so SEQUENCER there forwards messages to the new coordinator
- but because the new coordinator doesn't yet know that it is coordinator, we hit the problem above.
The messages don't ever get retransmitted; so they're simply lost.
Here's some trace from the member who drops the message, with the line from my application showing that he does indeed become coordinator a few milliseconds later:
2012-04-13 10:05:21.363 [Incoming-1,pisces,CFS-B-pisces-cfs02] ERROR org.jgroups.protocols.SEQUENCER - CFS-B-pisces-cfs02: non-coord; dropping FORWARD request from CFS-A-pisces-cfs03
2012-04-13 10:05:21.393 [Incoming-2,pisces,CFS-B-pisces-cfs02] INFO c.m.c.CommunicatorComponent$Communicator - New view: MergeView::[CFS-B-pisces-cfs02|86] [CFS-B-pisces-cfs02, CFS-B-pisces-cfs03, CFS-A-pisces-cfs03, CFS-A-pisces-cfs02], subgroups=[CFS-A-pisces-cfs03|84] [CFS-A-pisces-cfs03, CFS-A-pisces-cfs02], [CFS-B-pisces-cfs03|85] [CFS-B-pisces-cfs03, CFS-A-pisces-cfs02, CFS-B-pisces-cfs02]
And here's trace from the other end, showing that message being broadcast in the new view.
2012-04-13 10:05:21.359 [Incoming-1,pisces,CFS-A-pisces-cfs03] INFO c.m.c.CommunicatorComponent$Communicator - New view: MergeView::[CFS-B-pisces-cfs02|86] [CFS-B-pisces-cfs02, CFS-B-pisces-cfs03, CFS-A-pisces-cfs03, CFS-A-pisces-cfs02], subgroups=[CFS-A-pisces-cfs03|84] [CFS-A-pisces-cfs03, CFS-A-pisces-cfs02], [CFS-B-pisces-cfs03|85] [CFS-B-pisces-cfs03, CFS-A-pisces-cfs02, CFS-B-pisces-cfs02]
2012-04-13 10:05:21.361 [ForkJoinPool-1-worker-0] INFO c.m.c.CommunicatorComponent$Communicator - Broadcasting ClusterMgmtMsg
I can try to get lower level trace from JGroups if that would help.
I'm using the same stack as in JGRP-1443.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-4787) CLONE - Host controller hangs intermitentlly when connecting to domain controller
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/AS7-4787?page=com.atlassian.jira.plugin.s... ]
Emanuel Muckenhuber resolved AS7-4787.
--------------------------------------
Resolution: Cannot Reproduce Bug
> CLONE - Host controller hangs intermitentlly when connecting to domain controller
> ---------------------------------------------------------------------------------
>
> Key: AS7-4787
> URL: https://issues.jboss.org/browse/AS7-4787
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Dominik Pospisil
> Assignee: Emanuel Muckenhuber
> Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
>
>
> Host controller hangs intermittently when connecting to domain controller. Host controller is stuck forever and never recovers from this sistuation.
> I have never experienced this on local network, however this is pretty easy to reproduce using wireless network. The testing was done on private local wireless network with zero packet outages:
> 6973 packets transmitted, 6969 received, 0% packet loss, time 25334ms
> rtt min/avg/max/mdev = 1.398/4.318/284.480/11.672 ms, pipe 15, ipg/ewma 3.633/2.775 ms
> Also, the problem seems to be affecting only connecting - once the connection is made, all the management operations are performed correctly without problems.
> Logs from connecting hc:
> 14:37:01,827 INFO [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA-redhat-1
> 14:37:01,973 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 14:37:03,957 INFO [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA-redhat-1
> [Host Controller] 14:37:04,280 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA-redhat-1
> [Host Controller] 14:37:04,674 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.0.0.GA (AS 7.1.1.Final-redhat-1) starting
> [Host Controller] 14:37:05,919 INFO [org.xnio] (MSC service thread 1-4) XNIO Version 3.0.3.GA-redhat-1
> [Host Controller] 14:37:05,943 INFO [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.0.3.GA-redhat-1
> [Host Controller] 14:37:05,963 INFO [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.2.4.GA-redhat-1
> [Host Controller] 14:37:06,018 INFO [org.jboss.as.remoting] (MSC service thread 1-4) JBAS017100: Listening on 192.168.1.67:9999
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (AS7-4787) CLONE - Host controller hangs intermitentlly when connecting to domain controller
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/AS7-4787?page=com.atlassian.jira.plugin.s... ]
Emanuel Muckenhuber closed AS7-4787.
------------------------------------
> CLONE - Host controller hangs intermitentlly when connecting to domain controller
> ---------------------------------------------------------------------------------
>
> Key: AS7-4787
> URL: https://issues.jboss.org/browse/AS7-4787
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Dominik Pospisil
> Assignee: Emanuel Muckenhuber
> Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
>
>
> Host controller hangs intermittently when connecting to domain controller. Host controller is stuck forever and never recovers from this sistuation.
> I have never experienced this on local network, however this is pretty easy to reproduce using wireless network. The testing was done on private local wireless network with zero packet outages:
> 6973 packets transmitted, 6969 received, 0% packet loss, time 25334ms
> rtt min/avg/max/mdev = 1.398/4.318/284.480/11.672 ms, pipe 15, ipg/ewma 3.633/2.775 ms
> Also, the problem seems to be affecting only connecting - once the connection is made, all the management operations are performed correctly without problems.
> Logs from connecting hc:
> 14:37:01,827 INFO [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA-redhat-1
> 14:37:01,973 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 14:37:03,957 INFO [org.jboss.modules] (main) JBoss Modules version 1.1.2.GA-redhat-1
> [Host Controller] 14:37:04,280 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.2.GA-redhat-1
> [Host Controller] 14:37:04,674 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.0.0.GA (AS 7.1.1.Final-redhat-1) starting
> [Host Controller] 14:37:05,919 INFO [org.xnio] (MSC service thread 1-4) XNIO Version 3.0.3.GA-redhat-1
> [Host Controller] 14:37:05,943 INFO [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.0.3.GA-redhat-1
> [Host Controller] 14:37:05,963 INFO [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.2.4.GA-redhat-1
> [Host Controller] 14:37:06,018 INFO [org.jboss.as.remoting] (MSC service thread 1-4) JBAS017100: Listening on 192.168.1.67:9999
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months