[JBoss JIRA] (JGRP-2227) Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
by Robert Cernak (JIRA)
[ https://issues.jboss.org/browse/JGRP-2227?page=com.atlassian.jira.plugin.... ]
Robert Cernak commented on JGRP-2227:
-------------------------------------
In our application we have 2 jgroups communications channels. One for infinispan communication and second for sending commands between nodes.
I realized that it will be more beneficial to focus to this 2nd mentioned pure jgroups "commands channel", so we will separate any relation to Infinispan.
So I made test case again. This time I made try/catch block on place where this command channel is being created and connected:
{code:java}
this.commandsChannel = new JChannel(this.commandsChannelFile);
this.commandsChannel.setName(nodeName + "-" + String.format("%05x", new Random().nextInt(0xfffff)));
this.commandsChannel.setDiscardOwnMessages(true);
try {
this.commandsChannel.connect(createClusterNameForChannel(clusterName));
} catch (Exception e) {
System.out.println("Here should be thrown SecurityException");
}
//this.commandsChannel is org.jgroups.JChannel
{code}
I started node 1, in logs can be seen that it correctly forms new cluster as the first member. After that I started node 2. In logs can be seen that it tries to connect for 10 times and afterwards it forms new cluster. However no SecurityException was thrown.
Including trace logs from both nodes for org.jgroups.protocols and as well only logs for org.jgroups.protocols.pbcast.GMS:
[^traceLogs.zip]
> Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2227
> URL: https://issues.jboss.org/browse/JGRP-2227
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Robert Cernak
> Assignee: Bela Ban
> Fix For: 4.0.12
>
> Attachments: jgroupsDoesNotThrowSecurityExceptionWithJgroups4012.zip, jgroupsLogs.zip, traceLogs.zip
>
>
> I implemented method org.jgroups.auth.AuthToken#authenticate(AuthToken token, Message msg) in my class and its body contained only one line: return false;
> In this way authentication should be false and I should get SecurityException.
> When I started joining of nodes together to form a cluster, instead of getting SecurityException, nodes formed 2 different clusters with the same name.
> I am sure method was evaluated, since I tried to run it also with breakpoint, which was triggered during joining process.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (JGRP-2227) Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
by Robert Cernak (JIRA)
[ https://issues.jboss.org/browse/JGRP-2227?page=com.atlassian.jira.plugin.... ]
Robert Cernak updated JGRP-2227:
--------------------------------
Attachment: traceLogs.zip
> Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2227
> URL: https://issues.jboss.org/browse/JGRP-2227
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Robert Cernak
> Assignee: Bela Ban
> Fix For: 4.0.12
>
> Attachments: jgroupsDoesNotThrowSecurityExceptionWithJgroups4012.zip, jgroupsLogs.zip, traceLogs.zip
>
>
> I implemented method org.jgroups.auth.AuthToken#authenticate(AuthToken token, Message msg) in my class and its body contained only one line: return false;
> In this way authentication should be false and I should get SecurityException.
> When I started joining of nodes together to form a cluster, instead of getting SecurityException, nodes formed 2 different clusters with the same name.
> I am sure method was evaluated, since I tried to run it also with breakpoint, which was triggered during joining process.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Rahamathulla MJ (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Rahamathulla MJ commented on WFLY-6173:
---------------------------------------
Hi,
this is happening in RHAMT Web interface also. is this fixed? in which version. The version that is coming along with RHAMT Web is 10.1.0.Final. please confirm.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: Screen Shot 2016-10-27 at 08.04.12.png, Screen Shot 2016-10-27 at 08.15.27.png, memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFWIP-11) [Artemis upgrade] Regression in replicated HA tests
by Michal Toth (JIRA)
[ https://issues.jboss.org/browse/WFWIP-11?page=com.atlassian.jira.plugin.s... ]
Michal Toth commented on WFWIP-11:
----------------------------------
Related issue is fixed. Who should close this item?
> [Artemis upgrade] Regression in replicated HA tests
> ---------------------------------------------------
>
> Key: WFWIP-11
> URL: https://issues.jboss.org/browse/WFWIP-11
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Erich Duda
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: feature-branch-blocker
>
> *Scenario*
> * There are two servers configured as replicated Live-Backup pair
> * Live server is killed
> * Test waits until Backup server activates
> * Live server is restarted
> * Test expects that Backup server deactivates and Live becomes active
> *Reality:*
> Sometimes happens that Live server doesn't become active. In the log I can see that it was synchronized with Backup, but based on quorum vote, it was restarted as Backup.
> *Customer impact:* Failback feature in replicated HA is unstable.
> {code:title=Live}
> 12:26:51,011 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221109: Apache ActiveMQ Artemis Backup Server version 2.5.0-SNAPSHOT [null] started, waiting live to fail before it gets active
> 12:26:51,013 INFO [org.apache.activemq.artemis.core.client] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ211002: Started EPOLL Netty Connector version unknown to localhost:9080
> 12:26:52,344 INFO [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-client-netty-threads)) AMQ221024: Backup server ActiveMQServerImpl::serverUUID=a9e2f7d1-0742-11e8-bd92-54ee7553e6a7 is synchronized with live-server.
> 12:26:52,386 INFO [org.apache.activemq.artemis.core.client] (Thread-5 (ActiveMQ-client-netty-threads)) AMQ211002: Started EPOLL Netty Connector version unknown to localhost:9080
> 12:26:52,423 INFO [org.apache.activemq.artemis.core.server] (Thread-5 (ActiveMQ-client-netty-threads)) AMQ221070: Restarting as backup based on quorum vote results.
> {code}
> {code:title=Backup}
> 12:26:51,435 INFO [org.apache.activemq.artemis.core.server] (Thread-152) AMQ221025: Replication: sending AIOSequentialFile:/home/eduda/Projects/messaging-testsuite/server2/jboss-eap/standalone/data/../../../../
> hornetq-journal-B/journal/activemq-data-11.amq (size=10 485 760) to replica.
> 12:26:51,766 INFO [org.apache.activemq.artemis.core.server] (Thread-152) AMQ221025: Replication: sending AIOSequentialFile:/home/eduda/Projects/messaging-testsuite/server2/jboss-eap/standalone/data/../../../../
> hornetq-journal-B/journal/activemq-data-4.amq (size=10 485 760) to replica.
> 12:26:51,884 INFO [org.apache.activemq.artemis.core.server] (Thread-152) AMQ221025: Replication: sending NIOSequentialFile /home/eduda/Projects/messaging-testsuite/server2/jboss-eap/standalone/data/../../../../
> hornetq-journal-B/bindings/activemq-bindings-4.bindings (size=1 048 576) to replica.
> 12:26:51,890 INFO [org.apache.activemq.artemis.core.server] (Thread-152) AMQ221025: Replication: sending NIOSequentialFile /home/eduda/Projects/messaging-testsuite/server2/jboss-eap/standalone/data/../../../../
> hornetq-journal-B/bindings/activemq-bindings-2.bindings (size=1 048 576) to replica.
> 12:26:52,388 WARN [org.apache.activemq.artemis.core.client] (Thread-4 (ActiveMQ-client-global-threads)) AMQ212037: Connection failure has been detected: AMQ119015: The connection was disconnected because of ser
> ver shutdown [code=DISCONNECTED]
> 12:26:52,391 WARN [org.jboss.activemq.artemis.wildfly.integration.recovery] (Thread-4 (ActiveMQ-client-global-threads)) being disconnected for server shutdown: ActiveMQDisconnectedException[errorType=DISCONNECT
> ED message=AMQ119015: The connection was disconnected because of server shutdown]
> at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:996) [artemis-core-client-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_151]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_151]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_151]
> 12:26:52,396 WARN [org.apache.activemq.artemis.core.server] (default I/O-9) AMQ222061: Client connection failed, clearing up resources for session c12b0cb8-0742-11e8-8a8a-54ee7553e6a7
> 12:26:52,397 WARN [org.apache.activemq.artemis.core.server] (default I/O-9) AMQ222107: Cleared up resources for session c12b0cb8-0742-11e8-8a8a-54ee7553e6a7
> 12:26:52,397 WARN [org.apache.activemq.artemis.core.server] (default I/O-9) AMQ222061: Client connection failed, clearing up resources for session c12da4cb-0742-11e8-8a8a-54ee7553e6a7
> 12:26:52,397 WARN [org.apache.activemq.artemis.core.server] (default I/O-9) AMQ222107: Cleared up resources for session c12da4cb-0742-11e8-8a8a-54ee7553e6a7
> 12:26:52,412 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-1) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
> 12:26:52,412 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-8) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
> 12:26:52,412 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 74) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
> 12:26:52,413 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 107) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:/ConnectionFactory
> 12:26:52,416 INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 108) AMQ151003: resource adaptor stopped
> 12:26:52,458 WARN [org.apache.activemq.artemis.core.server] (default I/O-13) AMQ222092: Connection to the backup node failed, removing replication now: ActiveMQRemoteDisconnectException[errorType=REMOTE_DISCONNECT message=null]
> at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:553)
> at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:768)
> at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelInactive(ActiveMQChannelHandler.java:78)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:224)
> at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:377)
> at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:342)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:224)
> at io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1354)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231)
> at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:917)
> at io.netty.channel.AbstractChannel$AbstractUnsafe$8.run(AbstractChannel.java:822)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612) [xnio-nio-3.5.4.Final.jar:3.5.4.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:479) [xnio-nio-3.5.4.Final.jar:3.5.4.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-6405) Performance: WeldDeployment.getBeanDeploymentArchive method is synchronized
by Jan Swaelens (JIRA)
[ https://issues.jboss.org/browse/WFLY-6405?page=com.atlassian.jira.plugin.... ]
Jan Swaelens commented on WFLY-6405:
------------------------------------
Thanks [~kabirkhan]
> Performance: WeldDeployment.getBeanDeploymentArchive method is synchronized
> ---------------------------------------------------------------------------
>
> Key: WFLY-6405
> URL: https://issues.jboss.org/browse/WFLY-6405
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading
> Affects Versions: 10.0.0.Final
> Reporter: Panos Grigoropoulos
> Assignee: Stuart Douglas
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> (Wildfly 10.0.0.FINAL)
> During the performance test of my app (50 concurrent users with jmeter) I am running into the following issue:
> There are locked threads in the method WeldDeployment.getBeanDeploymentArchive(). Looking the code, this method is synchronized, so it makes sense. The question is, is this the expected behavior or this is a bug. In both cases is there any workaround to overcome this limitation?
> STACK TRACE:
> ....
> org.jboss.as.weld.WeldProvider$CdiImpl.getBeanManager():73
> org.jboss.as.weld.WeldProvider$CdiImpl.getBeanManager():93
> org.jboss.as.weld.deployment.WeldDeployment.getBeanDeploymentArchive():226
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (JGRP-2227) Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2227?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2227:
--------------------------------
Perhaps the members don't find each other? If B starts and doesn't find A in the discovery process, then of course no exception will be thrown.
I suggest setting a breakpoint in {{JChannel._connect(Event evt)}}, to see what's going on. Also, if you enable trace logging of {{GMS}} and your discovery protocol (e.g. {{PING}}), you'll see whether B discovers A, or not.
> Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2227
> URL: https://issues.jboss.org/browse/JGRP-2227
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Robert Cernak
> Assignee: Bela Ban
> Fix For: 4.0.12
>
> Attachments: jgroupsDoesNotThrowSecurityExceptionWithJgroups4012.zip, jgroupsLogs.zip
>
>
> I implemented method org.jgroups.auth.AuthToken#authenticate(AuthToken token, Message msg) in my class and its body contained only one line: return false;
> In this way authentication should be false and I should get SecurityException.
> When I started joining of nodes together to form a cluster, instead of getting SecurityException, nodes formed 2 different clusters with the same name.
> I am sure method was evaluated, since I tried to run it also with breakpoint, which was triggered during joining process.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months