[JBoss JIRA] (REMJMX-82) Jconsole doesn't connect JBOSS server 6.1.0 locally
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-82?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned REMJMX-82:
--------------------------------------
Assignee: Darran Lofthouse
> Jconsole doesn't connect JBOSS server 6.1.0 locally
> ---------------------------------------------------
>
> Key: REMJMX-82
> URL: https://issues.jboss.org/browse/REMJMX-82
> Project: Remoting JMX
> Issue Type: Bug
> Environment: Windows , JDK 1.6_21
> Reporter: Rajan Chaturvedi
> Assignee: Darran Lofthouse
>
> Hi
> We are moving application from JBOSS 4.X to JBOSS EAP 6.1.0.
> We are unable to connect JMS console . Every time we got follwoing
> error at JCONSOLE
> Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Error connecting to JBoss AS.
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:80)
> at sun.tools.jconsole.VMPanel.createPluginTabs(VMPanel.java:641)
> at sun.tools.jconsole.VMPanel.propertyChange(VMPanel.java:315)
> at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
> at javax.swing.event.SwingPropertyChangeSupport.firePropertyChange(SwingPropertyChangeSupport.java:75)
> at javax.swing.event.SwingPropertyChangeSupport$1.run(SwingPropertyChangeSupport.java:80)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.connectCommandContext(JConsoleCLIPlugin.java:109)
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:77)
> ... 13 more
> This Error is coming after adding jline-0.9.94-redhat-1.jar.
> at %JBOSS_MODULEPATH%\jline\main\jline-0.9.94-redhat-1.jar.
> Note that we are doing custom deployment hence written new bat file to start server which set few paths and then calls standalone.bat.
> Please provide solution ASAP.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (REMJMX-82) Jconsole doesn't connect JBOSS server 6.1.0 locally
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-82?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated REMJMX-82:
-----------------------------------
Original Estimate: (was: 4 days)
Remaining Estimate: (was: 4 days)
Workaround: (was: Workaround Exists)
Affects: (was: Compatibility/Configuration)
> Jconsole doesn't connect JBOSS server 6.1.0 locally
> ---------------------------------------------------
>
> Key: REMJMX-82
> URL: https://issues.jboss.org/browse/REMJMX-82
> Project: Remoting JMX
> Issue Type: Bug
> Environment: Windows , JDK 1.6_21
> Reporter: Rajan Chaturvedi
>
> Hi
> We are moving application from JBOSS 4.X to JBOSS EAP 6.1.0.
> We are unable to connect JMS console . Every time we got follwoing
> error at JCONSOLE
> Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Error connecting to JBoss AS.
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:80)
> at sun.tools.jconsole.VMPanel.createPluginTabs(VMPanel.java:641)
> at sun.tools.jconsole.VMPanel.propertyChange(VMPanel.java:315)
> at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
> at javax.swing.event.SwingPropertyChangeSupport.firePropertyChange(SwingPropertyChangeSupport.java:75)
> at javax.swing.event.SwingPropertyChangeSupport$1.run(SwingPropertyChangeSupport.java:80)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.connectCommandContext(JConsoleCLIPlugin.java:109)
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:77)
> ... 13 more
> This Error is coming after adding jline-0.9.94-redhat-1.jar.
> at %JBOSS_MODULEPATH%\jline\main\jline-0.9.94-redhat-1.jar.
> Note that we are doing custom deployment hence written new bat file to start server which set few paths and then calls standalone.bat.
> Please provide solution ASAP.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (REMJMX-82) Jconsole doesn't connect JBOSS server 6.1.0 locally
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/REMJMX-82?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse moved JBJMX-116 to REMJMX-82:
----------------------------------------------
Project: Remoting JMX (was: JBoss JMX)
Key: REMJMX-82 (was: JBJMX-116)
> Jconsole doesn't connect JBOSS server 6.1.0 locally
> ---------------------------------------------------
>
> Key: REMJMX-82
> URL: https://issues.jboss.org/browse/REMJMX-82
> Project: Remoting JMX
> Issue Type: Bug
> Environment: Windows , JDK 1.6_21
> Reporter: Rajan Chaturvedi
> Original Estimate: 4 days
> Remaining Estimate: 4 days
>
> Hi
> We are moving application from JBOSS 4.X to JBOSS EAP 6.1.0.
> We are unable to connect JMS console . Every time we got follwoing
> error at JCONSOLE
> Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Error connecting to JBoss AS.
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:80)
> at sun.tools.jconsole.VMPanel.createPluginTabs(VMPanel.java:641)
> at sun.tools.jconsole.VMPanel.propertyChange(VMPanel.java:315)
> at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
> at javax.swing.event.SwingPropertyChangeSupport.firePropertyChange(SwingPropertyChangeSupport.java:75)
> at javax.swing.event.SwingPropertyChangeSupport$1.run(SwingPropertyChangeSupport.java:80)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
> at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
> at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
> at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.connectCommandContext(JConsoleCLIPlugin.java:109)
> at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:77)
> ... 13 more
> This Error is coming after adding jline-0.9.94-redhat-1.jar.
> at %JBOSS_MODULEPATH%\jline\main\jline-0.9.94-redhat-1.jar.
> Note that we are doing custom deployment hence written new bat file to start server which set few paths and then calls standalone.bat.
> Please provide solution ASAP.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JGRP-1826) Discovery: file-based discovery protocols should not send discovery requests
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1826?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1826:
--------------------------------
The discovery should not have to read N files in a bucket (e.g. 1000 files for 1000 nodes), as this is very slow: the REST API to could storage needs to issue 1000 HTTP requests, parse the responses etc...
First of all, we need to see if those HTTP requests use connection pooling and how many of those requests are sent in parallel.
Secondly, we should terminate the loop as soon as we've received a coordinator response.
Alternatively, we could create a special file ending in *.node.coord*, and only read the coord node(s). However, this would not get us the information (address-physical address mapping) of the other nodes...
> Discovery: file-based discovery protocols should not send discovery requests
> ----------------------------------------------------------------------------
>
> Key: JGRP-1826
> URL: https://issues.jboss.org/browse/JGRP-1826
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When a node stores its information in a directory ({{FILE_PING}}, {{S3_PING}} or {{GOOGLE_PING}}), then we can optimize discovery by implementing a few things:
> * After reading all files, we send each node (represented by a file) a discovery request. That node processes the request and sends back a discovery response. This is unneeded traffic, especially with large clusters. Instead
> ** Read all files and add the information read from the files into the local caches (logical_addr_cache, UUID cache etc). This is the same as processing discovery responses from all members
> * Determine the coordinators directly from the file information. Perhaps we could even create a special file which contains information about the coordinator.
> ** This would prevent partitions from happening when starting up a large number of nodes: as long as that special file exists, nobody else will take ownership of it. When the coord leaves or crashes, we atomically replace the special file
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (WFLY-3226) Add test cases to verify LDAP caching on security realms.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3226?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-3226:
----------------------------------------
Hello [~friler] for the moment I would suggest a public comment on the issue to make sure others are aware you are looking into this.
FYI there is a pull request in the queue to add support for LDAP referrals, this does make some changes to the tests so your changes would need to be applied after that one.
Just one additional point, testing of actual timeouts is probably not going to be possible, those kind of tests tend to delay the overall build and also risk introducing race conditions and intermittent failures into the testsuite which is never popular ;-)
> Add test cases to verify LDAP caching on security realms.
> ---------------------------------------------------------
>
> Key: WFLY-3226
> URL: https://issues.jboss.org/browse/WFLY-3226
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Test Suite
> Reporter: Darran Lofthouse
> Fix For: Awaiting Volunteers
>
>
> The existing test cases are based on a statically defined set of LDIFs, testing of caching could consider a couple of options: -
> 1 - Interceptors within ApacheDS to verify if calls hit the directory.
> 2 - Updates to the directory that would affect the outcome of tests if there is a cache hit, tests can then be repeated with and without clearing the cache.
> Note: It would be beneficial for this to use different users and groups and maybe even different partitions so that test ordering does not affect the outcome if changes are made to the directory.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (DROOLS-469) NoSuchMethodError at runtime while comparing org.joda.time.DateTime instances
by Davide Angelocola (JIRA)
Davide Angelocola created DROOLS-469:
----------------------------------------
Summary: NoSuchMethodError at runtime while comparing org.joda.time.DateTime instances
Key: DROOLS-469
URL: https://issues.jboss.org/browse/DROOLS-469
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.1.Final
Environment: OS: Macosx 10.9.2
Java version: 1.6.0_65, vendor: Apple Inc.
Reporter: Davide Angelocola
Assignee: Mark Proctor
Given the following rule:
---
import org.joda.time.DateTime;
rule "in the past"
when
exists DateTime( this < new DateTime() )
then
System.out.println("in the past");
end
---
I obtain this exception at runtime while comparing a large number of DateTimes:
// java.lang.NoSuchMethodError: org.joda.time.DateTime.compareTo(Lorg/joda/time/DateTime;)I
// at ConditionEvaluatorc959ae5f82e8456f9e4f2d8b7e07b19d.evaluate(Unknown Source)
// at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
// at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
// at org.drools.core.phreak.PhreakFromNode.checkConstraintsAndPropagate(PhreakFromNode.java:298)
// at org.drools.core.phreak.PhreakFromNode.doLeftInserts(PhreakFromNode.java:101)
// at org.drools.core.phreak.PhreakFromNode.doNode(PhreakFromNode.java:49)
// at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:348)
// at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:604)
// at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:528)
// at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JGRP-1821) SEQUENCER2: new impl of total order protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1821?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1821.
----------------------------
Resolution: Done
> SEQUENCER2: new impl of total order protocol
> --------------------------------------------
>
> Key: JGRP-1821
> URL: https://issues.jboss.org/browse/JGRP-1821
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When in {{SEQUENCER}} a member P wants to send a multicast message M, it unicasts it to the coordinator, who multicasts it on behalf of P.
> The new impl {{SEQUENCER2}} is different:
> * P asks the coord for a seqno
> * The coord responds with a (monotonically increasing) seqno
> * P multicasts M with that seqno
> * Everyone uses one global {{Table}} to deliver messages and weed out duplicates
> Advantages:
> # A sender sends messages itself, so the sequencer doesn't need to do sending (and potential retransmissions)
> # Compared to {{SEQUENCER}}, the data is only sent and marshalled once (better for large messages)
> # A sender grabs entire ranges of seqnos, so this should be efficient
> The edge case handling though requires some work, e.g.
> * A member B crashes after having received a seqno (e.g. 4)
> ** The sequencer will give out 5 next, but since nobody received 4, all subsequent messages will get stuck, waiting for 4
> * The sequencer (coord) dies or leaves
> ** The next-in-line probably needs to run some reconciliation protocol, asking all members for their highest received seqnos
> ** Messages like 4 would get marked as dummy, removed from table and dropped
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JGRP-1821) SEQUENCER2: new impl of total order protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1821?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1821:
--------------------------------
This impl needs more work in 4.0
> SEQUENCER2: new impl of total order protocol
> --------------------------------------------
>
> Key: JGRP-1821
> URL: https://issues.jboss.org/browse/JGRP-1821
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When in {{SEQUENCER}} a member P wants to send a multicast message M, it unicasts it to the coordinator, who multicasts it on behalf of P.
> The new impl {{SEQUENCER2}} is different:
> * P asks the coord for a seqno
> * The coord responds with a (monotonically increasing) seqno
> * P multicasts M with that seqno
> * Everyone uses one global {{Table}} to deliver messages and weed out duplicates
> Advantages:
> # A sender sends messages itself, so the sequencer doesn't need to do sending (and potential retransmissions)
> # Compared to {{SEQUENCER}}, the data is only sent and marshalled once (better for large messages)
> # A sender grabs entire ranges of seqnos, so this should be efficient
> The edge case handling though requires some work, e.g.
> * A member B crashes after having received a seqno (e.g. 4)
> ** The sequencer will give out 5 next, but since nobody received 4, all subsequent messages will get stuck, waiting for 4
> * The sequencer (coord) dies or leaves
> ** The next-in-line probably needs to run some reconciliation protocol, asking all members for their highest received seqnos
> ** Messages like 4 would get marked as dummy, removed from table and dropped
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] (JGRP-1687) CastMessageWithFuture in MessageDispatcher
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1687?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1687.
----------------------------
Resolution: Done
Merged onto master (3.5), will not get backported to the 3.4 branch
> CastMessageWithFuture in MessageDispatcher
> -------------------------------------------
>
> Key: JGRP-1687
> URL: https://issues.jboss.org/browse/JGRP-1687
> Project: JGroups
> Issue Type: Bug
> Reporter: shen kim
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When I used CastMessageWithFuture in MessageDispatcher. I found the following Method declared :
> public <T> NotifyingFuture<RspList<T>> castMessageWithFuture(java.util.Collection<Address> dests, Message RequestOptions options, FutureListener<T> listener) throws java.lang.Exception
> Is it the FutureListener<T> may be declared to FutureListener<RspList<T>> ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months