[JBoss JIRA] (WFCORE-1478) DefaultOperationRequestAddress.appendPath loses Node.name
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-1478:
--------------------------------------------
Summary: DefaultOperationRequestAddress.appendPath loses Node.name
Key: WFCORE-1478
URL: https://issues.jboss.org/browse/WFCORE-1478
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Alexey Loubyansky
Ran into this obvious issue reading code. Not even sure this method is used somewhere.
for(Node n : path) {
nodes.add(new NodeImpl(n.getType(),* n.getType()*));
}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGTOOL-104) FQCN and an import improperly deconflicted - FQCN lost
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-104?page=com.atlassian.jira.plugi... ]
Arcadiy Ivanov updated LOGTOOL-104:
-----------------------------------
Steps to Reproduce:
To the {{org.jboss.logging.processor.generated.TransformLogger}} add {{import java.util.List;}} and add the following messages:
{code}
@LogMessage
@Message("Irrelevant typeTest1 message %s")
void typeTest1(List list);
@LogMessage
@Message("Irrelevant typeTest2 message %s")
void typeTest2(java.awt.List list);
{code}
Observe the test failure at the processing level.
was:
To the {{org.jboss.logging.processor.generated.TransformLogger}} add {{import java.util.List;}} and add the following messages:
{code}
@LogMessage
@Message("Irrelevant typeTest1 message %s")
void typeTest1(List list);
@LogMessage
@Message("Irrelevant typeTest2 message %s")
void typeTest2(java.awt.List list);
{code}
Observe the test failure a the processing level.
> FQCN and an import improperly deconflicted - FQCN lost
> ------------------------------------------------------
>
> Key: LOGTOOL-104
> URL: https://issues.jboss.org/browse/LOGTOOL-104
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: Arcadiy Ivanov
>
> Given:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @MessageLogger(projectCode = "JBOSGI")
> public interface FrameworkLogger extends BasicLogger {
> @LogMessage(level = WARN)
> @Message(id = 11019, value = "Error while calling event hook: %s")
> void warnErrorWhileCallingEventHook(@Cause Throwable cause, EventHook hook);
> @LogMessage(level = WARN)
> @Message(id = 11040, value = "Error while calling bundle event hook: %s")
> void warnErrorWhileCallingBundleEventHook(@Cause Throwable cause, org.osgi.framework.hooks.bundle.EventHook hook);
> }
> {code}
> Compilation failure:
> {quote}
> ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[26,8] org.jboss.osgi.framework.FrameworkLogger_$logger is not abstract and does not override abstract method warnErrorWhileCallingBundleEventHook(java.lang.Throwable,org.osgi.framework.hooks.bundle.EventHook) in org.jboss.osgi.framework.FrameworkLogger
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[336,5] method does not override or implement a method from a supertype
> {quote}
> Cause:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @Generated(value = "org.jboss.logging.processor.generator.model.MessageLoggerImplementor", date = "2016-04-18T04:40:24-0400")
> public class FrameworkLogger_$logger extends DelegatingBasicLogger implements FrameworkLogger,BasicLogger,Serializable {
> @Override
> public final void warnErrorWhileCallingEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingEventHook$str(), hook);
> }
> @Override
> public final void warnErrorWhileCallingBundleEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingBundleEventHook$str(), hook);
> }
> }
> {code}
> As you can see the cause of the failure is that {{EventHook}} argument FQCN is lost in the generated {{warnErrorWhileCallingBundleEventHook}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (LOGTOOL-104) FQCN and an import improperly deconflicted - FQCN lost
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-104?page=com.atlassian.jira.plugi... ]
Arcadiy Ivanov updated LOGTOOL-104:
-----------------------------------
Steps to Reproduce:
To the {{org.jboss.logging.processor.generated.TransformLogger}} add {{import java.util.List;}} and add the following messages:
{code}
@LogMessage
@Message("Irrelevant typeTest1 message %s")
void typeTest1(List list);
@LogMessage
@Message("Irrelevant typeTest2 message %s")
void typeTest2(java.awt.List list);
{code}
Observe the test failure a the processing level.
> FQCN and an import improperly deconflicted - FQCN lost
> ------------------------------------------------------
>
> Key: LOGTOOL-104
> URL: https://issues.jboss.org/browse/LOGTOOL-104
> Project: Log Tool
> Issue Type: Bug
> Affects Versions: 2.0.1.Final
> Reporter: Arcadiy Ivanov
>
> Given:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @MessageLogger(projectCode = "JBOSGI")
> public interface FrameworkLogger extends BasicLogger {
> @LogMessage(level = WARN)
> @Message(id = 11019, value = "Error while calling event hook: %s")
> void warnErrorWhileCallingEventHook(@Cause Throwable cause, EventHook hook);
> @LogMessage(level = WARN)
> @Message(id = 11040, value = "Error while calling bundle event hook: %s")
> void warnErrorWhileCallingBundleEventHook(@Cause Throwable cause, org.osgi.framework.hooks.bundle.EventHook hook);
> }
> {code}
> Compilation failure:
> {quote}
> ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[26,8] org.jboss.osgi.framework.FrameworkLogger_$logger is not abstract and does not override abstract method warnErrorWhileCallingBundleEventHook(java.lang.Throwable,org.osgi.framework.hooks.bundle.EventHook) in org.jboss.osgi.framework.FrameworkLogger
> [ERROR] /Users/arcivanov/Documents/src/jbosgi/jbosgi-framework/core/target/generated-sources/annotations/org/jboss/osgi/framework/FrameworkLogger_$logger.java:[336,5] method does not override or implement a method from a supertype
> {quote}
> Cause:
> {code}
> import org.osgi.framework.hooks.service.EventHook;
> @Generated(value = "org.jboss.logging.processor.generator.model.MessageLoggerImplementor", date = "2016-04-18T04:40:24-0400")
> public class FrameworkLogger_$logger extends DelegatingBasicLogger implements FrameworkLogger,BasicLogger,Serializable {
> @Override
> public final void warnErrorWhileCallingEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingEventHook$str(), hook);
> }
> @Override
> public final void warnErrorWhileCallingBundleEventHook(final Throwable cause, final EventHook hook) {
> super.log.logf(FQCN, org.jboss.logging.Logger.Level.WARN, cause, warnErrorWhileCallingBundleEventHook$str(), hook);
> }
> }
> {code}
> As you can see the cause of the failure is that {{EventHook}} argument FQCN is lost in the generated {{warnErrorWhileCallingBundleEventHook}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1417) org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1417?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1417:
----------------------------------------------
Re-opening since the original PR had failing tests.
> org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1417
> URL: https://issues.jboss.org/browse/WFCORE-1417
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.CR1
> Reporter: Tom Fonteyne
> Assignee: Jean-Francois Denise
> Priority: Minor
>
> cli/src/main/java/org/jboss/as/cli/scriptsupport/CLI.java
> public void connect() {
> checkAlreadyConnected();
> try {
> ctx = CommandContextFactory.getInstance().newCommandContext();
> ctx.connectController();
> } catch (CliInitializationException e) {
> throw new IllegalStateException("Unable to initialize command context.", e);
> } catch (CommandLineException e) {
> throw new IllegalStateException("Unable to connect to controller.", e);
> }
> }
> also applicable to the other connects of course.
> If the connection fails in the connect method, a subsequent connect will hit:
> private void checkAlreadyConnected() {
> if (ctx != null) throw new IllegalStateException("Already connected to server.");
> }
> and will fail for the wrong reason... as while ctx !=null is true, but the connection had failed.
> ergo, upon failure in connect, the ctx should be reset to avoid this
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1417) org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1417?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise reopened WFCORE-1417:
------------------------------------------
> org.jboss.as.cli.scriptsupport.CLI connect methods do not properly reset the ctx upon failure making in turn checkNotConnected() to report incorrectly
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1417
> URL: https://issues.jboss.org/browse/WFCORE-1417
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.1.0.CR1
> Reporter: Tom Fonteyne
> Assignee: Jean-Francois Denise
> Priority: Minor
>
> cli/src/main/java/org/jboss/as/cli/scriptsupport/CLI.java
> public void connect() {
> checkAlreadyConnected();
> try {
> ctx = CommandContextFactory.getInstance().newCommandContext();
> ctx.connectController();
> } catch (CliInitializationException e) {
> throw new IllegalStateException("Unable to initialize command context.", e);
> } catch (CommandLineException e) {
> throw new IllegalStateException("Unable to connect to controller.", e);
> }
> }
> also applicable to the other connects of course.
> If the connection fails in the connect method, a subsequent connect will hit:
> private void checkAlreadyConnected() {
> if (ctx != null) throw new IllegalStateException("Already connected to server.");
> }
> and will fail for the wrong reason... as while ctx !=null is true, but the connection had failed.
> ergo, upon failure in connect, the ctx should be reset to avoid this
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-2053) TCP: reduce blocking on BaseServer
by Bela Ban (JIRA)
Bela Ban created JGRP-2053:
------------------------------
Summary: TCP: reduce blocking on BaseServer
Key: JGRP-2053
URL: https://issues.jboss.org/browse/JGRP-2053
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6.10, 4.0
There's work that can be done outside of synchronized statements and locks, e.g. {{BaseServer.removeConnectionIfPresent()}} can close the connection outside the synchronized block. This block delays other threads, see attached dump.txt for details.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-2050) S3_PING: Nodes never removed from .list file
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2050?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2050.
----------------------------
Fix Version/s: 4.0
Resolution: Rejected
Use of {{logical_addr_cache_max_size}} fixes this, see my last comment on JGRP-1957. Please reopen if the issue still persists.
> S3_PING: Nodes never removed from .list file
> --------------------------------------------
>
> Key: JGRP-2050
> URL: https://issues.jboss.org/browse/JGRP-2050
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.6.8
> Reporter: Mitchell Ackerman
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> Unfortunately I seem to be running into the same or similar issue as JGRP-1957, even though I've updated to JGroups 3.6.8 and am using the settings you suggest in that (and other) posts.
> I'm running in AWS using S3_PING, JDK 1.8.0_66, JGroups 3.6.8, Tomcat 8.0.28.
> After terminating servers, mostly non-coordinators, I'm left with an S3 bucket with lots of zombies (there are only 2 active members), here is the file after the system has been stable for over an hour, and my JGroups config file.
> Stepping through the code, I have confirmed that the scenario is the same as described in JGRP-1957. upon a view change the new (correct) member list is written to S3, but then it is overwritten with all the old members. When the old members are added back to the logical_addr_cache they all have their removable field set to false, so that all subsequent evictions skip over these members and they are never removed.
> thanks, Mitchell
> ip-10-89-1-26-8729 72597f74-8a10-04fb-b397-22a3ed35da84 10.89.1.26:7800 F
> ip-10-89-0-18-38996 a5325932-e9cd-b281-b367-e2d86845aa75 10.89.0.18:7800 F
> ip-10-89-1-62-4868 ef73921a-2265-50a8-95d4-ebb8cae96944 10.89.1.62:7800 T
> ip-10-89-1-27-11915 5a0b4a26-b542-56f2-801a-420b5d7dbf34 10.89.1.27:7800 F
> ip-10-89-1-19-2542 c30c294d-69b0-b6ca-7010-bf89d1eb8f6f 10.89.1.19:7800 F
> ip-10-89-0-62-56914 fa2262c3-9097-7101-b225-24d8a52d905e 10.89.0.62:7800 F
> ip-10-89-0-28-32680 5d03124f-b061-becb-d793-6067bf0d7945 10.89.0.28:7800 F
> ip-10-89-1-26-51248 07cc18aa-381b-fb5d-0ad6-0612f7a5e9bb 10.89.1.26:7800 F
> ip-10-89-1-27-39755 1f9be940-2228-2181-ef80-4a83d319a2b3 10.89.1.27:7800 F
> ip-10-89-0-28-41919 4ab543f9-712e-645d-2f20-05304c98a23b 10.89.0.28:7800 F
> ip-10-89-1-27-10428 d5b0cb38-75e0-b3e1-c053-66b053b0fb05 10.89.1.27:7800 F
> my JGroups config file is:
> <?xml version="1.0" encoding="UTF-8"?>
> <config>
> <TCP
> bind_port="7800"
> port_range="30"
> recv_buf_size="20000000"
> send_buf_size="1000000"
> max_bundle_size="64000"
> max_bundle_timeout="1000"
> sock_conn_timeout="2000"
> enable_diagnostics="false"
> timer_type="new"
> timer.min_threads="4"
> timer.max_threads="10"
> timer.keep_alive_time="3000"
> timer.queue_max_size="1000"
> timer.wheel_size="200"
> timer.tick_time="50"
> thread_pool.enabled="true"
> thread_pool.min_threads="2"
> thread_pool.max_threads="100"
> thread_pool.keep_alive_time="60000"
> thread_pool.queue_enabled="true"
> thread_pool.queue_max_size="100000"
> thread_pool.rejection_policy="discard"
> oob_thread_pool.enabled="true"
> oob_thread_pool.min_threads="10"
> oob_thread_pool.max_threads="100"
> oob_thread_pool.keep_alive_time="60000"
> oob_thread_pool.queue_enabled="false"
> oob_thread_pool.queue_max_size="100"
> oob_thread_pool.rejection_policy="discard"
> logical_addr_cache_expiration="1000"
> logical_addr_cache_reaper_interval="10000"
> />
> <S3_PING location="bob-s3-ping-dev" remove_all_files_on_view_change="true" remove_old_coords_on_view_change="true"/>
> <MERGE3 max_interval="60000" min_interval="30000"/>
> <FD_SOCK/>
> <FD timeout="3000" max_tries="5"/>
> <VERIFY_SUSPECT timeout="2000"/>
> <pbcast.NAKACK use_mcast_xmit="false" retransmit_timeout="300,600,1200,2400,4800" discard_delivered_msgs="true"/>
> <UNICAST3/>
> <pbcast.STABLE stability_delay="1500" desired_avg_gossip="50000" max_bytes="2m"/>
> <pbcast.GMS print_local_addr="false" join_timeout="2500" max_bundling_time="50" view_bundling="true" max_join_attempts="$
> {jgroups_max_join_attempts}
> "/>
> <pbcast.STATE_TRANSFER />
> <!-- top -->
> <!-- /\ down -->
> <!-- \/ up -->
> </config>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years