[JBoss JIRA] (AS7-5403) CLONE - Adding modcluster via the CLI fails.
by Joe Wertz (JIRA)
[ https://issues.jboss.org/browse/AS7-5403?page=com.atlassian.jira.plugin.s... ]
Joe Wertz commented on AS7-5403:
--------------------------------
A more elegant solution as requested.
Adding a ListAttributeDefinition to the ModClusterDefinition. ModClusterConfigAttributeDefinition. The new attribute definition essentially replicates the ModClusterConfigResourceDefinition as an attribute so that it can be used during the ./subsystem=modcluster:add(__) command. This way the user can input configuration values before the modcluster subsystem attempts to start up.
CLI Usage Example:
{noformat}
./subsystem=modcluster:add(configuration=[{advertise-socket=ajp,connector=ajp}])
{noformat}
Depending on how many of the configuration attributes the user wanted to define at the time. Only the connector would be required, like the ModClusterConfigResourceDefinition.
> CLONE - Adding modcluster via the CLI fails.
> --------------------------------------------
>
> Key: AS7-5403
> URL: https://issues.jboss.org/browse/AS7-5403
> Project: Application Server 7
> Issue Type: Bug
> Components: CLI
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Tom Fonteyne
> Assignee: Joe Wertz
>
> Adding modcluster via the CLI fails.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (JBRULES-3633) Allow encoding to be specified on a resource when using spring configuration
by Joachim Van der Auwera (JIRA)
Joachim Van der Auwera created JBRULES-3633:
-----------------------------------------------
Summary: Allow encoding to be specified on a resource when using spring configuration
Key: JBRULES-3633
URL: https://issues.jboss.org/browse/JBRULES-3633
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-spring
Affects Versions: 5.4.0.Final
Reporter: Joachim Van der Auwera
Assignee: Mark Proctor
Currently default encoding (which is platform specific) is used when reading resources. This can give problems when the resource (for example a rules file) is written using a different encoding.
--
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
[JBoss JIRA] (AS7-5585) logging.properties broken on Windows after file is rewritten
by James Perkins (JIRA)
James Perkins created AS7-5585:
----------------------------------
Summary: logging.properties broken on Windows after file is rewritten
Key: AS7-5585
URL: https://issues.jboss.org/browse/AS7-5585
Project: Application Server 7
Issue Type: Bug
Components: Logging
Environment: Windows
Reporter: James Perkins
Assignee: James Perkins
Priority: Blocker
Fix For: 7.2.0.Alpha1
The persistence of the logging.properties file writes out paths like C:\ on Windows which results in an error when trying to load the paths again.
--
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
[JBoss JIRA] (AS7-5536) servlet lifecycle interceptor methods ignored when declared in web.xml
by Cheng Fang (JIRA)
Cheng Fang created AS7-5536:
-------------------------------
Summary: servlet lifecycle interceptor methods ignored when declared in web.xml
Key: AS7-5536
URL: https://issues.jboss.org/browse/AS7-5536
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.2.0.Alpha1
Reporter: Cheng Fang
Assignee: Remy Maucherat
web.xml declares post-construct and pre-destroy methods, but are not invoked during the servlet lifecycle.
{code:xml}
<post-construct>
<lifecycle-callback-class>test.TestServlet</lifecycle-callback-class>
<lifecycle-callback-method>ps</lifecycle-callback-method>
</post-construct>
<pre-destroy>
<lifecycle-callback-class>test.TestServlet</lifecycle-callback-class>
<lifecycle-callback-method>pd</lifecycle-callback-method>
</pre-destroy>
{code}
The servlet class itself does not contain any @PostConstruct or @PreDestroy methods.
--
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
[JBoss JIRA] (AS7-5520) "IllegalStateException: channel is not connected" on clean shutdown
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-5520:
-----------------------------------
Summary: "IllegalStateException: channel is not connected" on clean shutdown
Key: AS7-5520
URL: https://issues.jboss.org/browse/AS7-5520
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Fix For: 7.1.3.Final (EAP)
The current fix in for AS7-5442 doesn't result in a timeout exception, Infinispan now checks whether channel is open however results in a WARN message.
Looks like AS is closing the channel before the cache is stopped.
{noformat}
[JBossINF] 06:25:23,758 INFO [org.jboss.as.clustering.infinispan] JBAS010282: Stopped default-host/clusterbench cache from web container
[JBossINF] 06:25:23,767 INFO [org.jboss.as.server.deployment] JBAS015877: Stopped deployment clusterbench-ee6-ejb.jar in 1061ms
[JBossINF] 06:25:23,765 WARN [org.infinispan.cacheviews.CacheViewsManagerImpl] ISPN000169: Error committing cache view 5 for cache default-host/clusterbench: org.infinispan.CacheException: java.lang.IllegalStateException: channel is not connected
[JBossINF] at org.infinispan.util.Util.rewrapAsCacheException(Util.java:526) [infinispan-core-5.1.7-SNAPSHOT.jar:5.1.7-SNAPSHOT]
[JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:139) [infinispan-core-5.1.7-SNAPSHOT.jar:5.1.7-SNAPSHOT]
[JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:492) [infinispan-core-5.1.7-SNAPSHOT.jar:5.1.7-SNAPSHOT]
[JBossINF] at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterCommitView(CacheViewsManagerImpl.java:378) [infinispan-core-5.1.7-SNAPSHOT.jar:5.1.7-SNAPSHOT]
[JBossINF] at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:272) [infinispan-core-5.1.7-SNAPSHOT.jar:5.1.7-SNAPSHOT]
[JBossINF] at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:894) [infinispan-core-5.1.7-SNAPSHOT.jar:5.1.7-SNAPSHOT]
[JBossINF] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_30]
[JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_30]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
[JBossINF] Caused by: java.lang.IllegalStateException: channel is not connected
[JBossINF] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:619) [jgroups-3.0.14.Final.jar:3.0.14.Final]
[JBossINF] at org.jgroups.blocks.RequestCorrelator.sendUnicastRequest(RequestCorrelator.java:193) [jgroups-3.0.14.Final.jar:3.0.14.Final]
[JBossINF] at org.jgroups.blocks.UnicastRequest.sendRequest(UnicastRequest.java:44) [jgroups-3.0.14.Final.jar:3.0.14.Final]
[JBossINF] at org.jgroups.blocks.Request.execute(Request.java:83) [jgroups-3.0.14.Final.jar:3.0.14.Final]
[JBossINF] at org.jgroups.blocks.MessageDispatcher.sendMessageWithFuture(MessageDispatcher.java:419) [jgroups-3.0.14.Final.jar:3.0.14.Final]
[JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processCalls(CommandAwareRpcDispatcher.java:329) [infinispan-core-5.1.7-SNAPSHOT.jar:5.1.7-SNAPSHOT]
[JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:132) [infinispan-core-5.1.7-SNAPSHOT.jar:5.1.7-SNAPSHOT]
[JBossINF] ... 9 more
[JBossINF]
[JBossINF] 06:25:23,768 INFO [org.jboss.as.server.deployment] JBAS015877: Stopped deployment clusterbench-ee6-web-granular.war in 1062ms
[JBossINF] 06:25:23,769 INFO [org.jboss.as.server.deployment] JBAS015877: Stopped deployment clusterbench-ee6-web.war in 1063ms
[JBossINF] 06:25:23,770 INFO [org.jboss.as.server.deployment] JBAS015877: Stopped deployment clusterbench-ee6.ear in 1076ms
[JBossINF] 06:25:24,128 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] ISPN000082: Stopping the RpcDispatcher
[JBossINF] 06:25:24,132 INFO [org.jboss.as] JBAS015950: JBoss AS 7.1.3.Final-SNAPSHOT "Arges" stopped in 1337ms
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (JGRP-1518) Logging: suppress identical warnings for a configurable time
by Bela Ban (JIRA)
Bela Ban created JGRP-1518:
------------------------------
Summary: Logging: suppress identical warnings for a configurable time
Key: JGRP-1518
URL: https://issues.jboss.org/browse/JGRP-1518
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Introduce a configurable time during which identical log warnings are suppressed. Examples:
- Suppress all warnings about messages received from a given member in a different clusters
- Suppress all warnings about messages received from a member running a different (incompatible) version of JGroups
- Suppress all warnings about messages received from a non-member
In UDP/TCP, the following properties are introduced:
- suppress_time_different_version_warnings
- suppress_time_different_cluster_warnings
- suppress_time_non_member_warnings
All times are milliseconds. 0 or a log level higher than WARN disables these.
Example:
- suppress_time_different_version_warnings=60000
When we have our cluster of {A,B,C} and 2 members X and Y which are running a different version, then we'll get *1 warning per member* every 10 seconds minimum. So if X and Y are sending messages then we do get warnings at A, B and C at the follwing times (ms, assuming X and Y both send a message):
- 0: 1 WARN for X, 1 WARN for Y
- 1000: <none>
- 4000: <none>
- 9000: <none>
- 10500: 1 WARN for X, 1 WARN for Y
- 12000: <none>
- 18000: <none>
- 21000: 1 WARN for X, 1 WARN for Y
- 50000: 1 WARN for X, 1 WARN for Y
and so on
- 1000:
--
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
[JBoss JIRA] (AS7-4140) Change distribution of -Dmcast through testsuite
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/AS7-4140?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar updated AS7-4140:
--------------------------------
Fix Version/s: 7.2.0.Alpha1
> Change distribution of -Dmcast through testsuite
> ------------------------------------------------
>
> Key: AS7-4140
> URL: https://issues.jboss.org/browse/AS7-4140
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Clustering, Test Suite
> Affects Versions: 7.1.1.Final
> Reporter: Pavel Janousek
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> Please change present behavior.
> We need to define only one property -Dmcast (for ex., the name doesn't matter now) as command line parameter - this multicast address is needed to be distributed to every subsystem which manages any multicast communication. It is needed to be unique in every subsystem - JGroups, HornetQ etc. because we must avoid to interfere each other => port assignation must be unique for every a such component.
> This change is needed in both - IPV4 and IPv6...
--
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
[JBoss JIRA] (JBRULES-3532) NPE in DefaultHardAndSoftScore.compareTo()
by Martin Vecera (JIRA)
Martin Vecera created JBRULES-3532:
--------------------------------------
Summary: NPE in DefaultHardAndSoftScore.compareTo()
Key: JBRULES-3532
URL: https://issues.jboss.org/browse/JBRULES-3532
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-eclipse (expert)
Affects Versions: 5.4.0.Final
Reporter: Martin Vecera
Assignee: Mark Proctor
When running a benchmark on a very slow machine (virtual machine), hard and soft part of the score might remain uninitialized for long time (might be related to JBRULES-3317). This discovered an issue in the compareTo() method.
Caused by: java.lang.NullPointerException
at org.drools.planner.core.score.buildin.hardandsoft.DefaultHardAndSoftScore.compareTo(DefaultHardAndSoftScore.java:125)
at org.drools.planner.core.score.buildin.hardandsoft.DefaultHardAndSoftScore.compareTo(DefaultHardAndSoftScore.java:27)
at org.drools.planner.benchmark.core.ProblemBenchmark.determineWinningResult(ProblemBenchmark.java:180)
at org.drools.planner.benchmark.core.ProblemBenchmark.benchmarkingEnded(ProblemBenchmark.java:173)
at org.drools.planner.benchmark.core.DefaultPlannerBenchmark.benchmarkingEnded(DefaultPlannerBenchmark.java:201)
at org.drools.planner.benchmark.core.DefaultPlannerBenchmark.benchmark(DefaultPlannerBenchmark.java:135)
at org.drools.planner.examples.tournaments.Benchmark.main(Benchmark.java:25)
... 6 more
--
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
12 years
[JBoss JIRA] (AS7-2411) servergroup view
by Rich Sharples (Created) (JIRA)
servergroup view
----------------
Key: AS7-2411
URL: https://issues.jboss.org/browse/AS7-2411
Project: Application Server 7
Issue Type: Feature Request
Components: Console
Affects Versions: 7.1.0.Alpha1
Environment: all
Reporter: Rich Sharples
Assignee: Heiko Braun
Fix For: 7.1.0.Beta1
In the console when working with a large cluster or server-group it would be *really* useful to have a single view of all servers (local and remote) within the group. In thatview I'd expect to see the server name as well as the host IP / name and status. I think the natural place for this view would be unde Server Groups.
The alterative today is to go to each host and view the server-group on each - that is a real pain in a production environment with a large number of machines / servers.
--
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
12 years