[JBoss JIRA] (WFLY-7856) Update tests to use the correct value for Context.PROVIDER_URL
by Farah Juma (JIRA)
Farah Juma created WFLY-7856:
--------------------------------
Summary: Update tests to use the correct value for Context.PROVIDER_URL
Key: WFLY-7856
URL: https://issues.jboss.org/browse/WFLY-7856
Project: WildFly
Issue Type: Bug
Components: Test Suite
Reporter: Farah Juma
Assignee: Farah Juma
Some tests currently set the Context.PROVIDER_URL property to "remote://localhost:4447" in addition to setting the Context.URL_PKG_PREFIXES property to "org.jboss.ejb.client.naming" when looking up an EJB using the "ejb:" prefix. With the old version of EJB client, the Context.PROVIDER_URL property was essentially ignored in this case so it didn't matter that port 4447 isn't the right port anymore. However, with the new version of EJB client (i.e., version 4.x), the following {{ConnectException}} now occurs in [RemoteEJBReceiver.getConnection()|https://github.com/jbossas/jboss-ejb-cl...] when attempting to invoke a method on the looked up EJB (since {{RemoteEJBReceiver.getConnection()}} now attempts to actually get the naming connection if the Context.PROVIDER_URL property was specified):
{code}
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:321)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:567)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:466)
at org.jboss.remoting3.FutureConnection.connect(FutureConnection.java:113)
at org.jboss.remoting3.FutureConnection.init(FutureConnection.java:75)
at org.jboss.remoting3.FutureConnection.get(FutureConnection.java:151)
at org.jboss.remoting3.EndpointImpl.getConnection(EndpointImpl.java:422)
at org.jboss.remoting3.UncloseableEndpoint.getConnection(UncloseableEndpoint.java:57)
at org.jboss.remoting3.Endpoint.getConnection(Endpoint.java:105)
at org.wildfly.naming.client.remote.RemoteNamingProvider.lambda$new$0(RemoteNamingProvider.java:68)
at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentity(RemoteNamingProvider.java:126)
at org.jboss.ejb.protocol.remote.RemoteEJBReceiver.getConnection(RemoteEJBReceiver.java:112)
at org.jboss.ejb.protocol.remote.RemoteEJBReceiver.processInvocation(RemoteEJBReceiver.java:77)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:313)
at org.jboss.ejb.client.EJBInvocationHandler.lambda$invoke$0(EJBInvocationHandler.java:158)
at org.jboss.ejb.client.EJBClientContext.performLocatedAction(EJBClientContext.java:297)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:149)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:99)
at com.sun.proxy.$Proxy23.trigger(Unknown Source)
at org.jboss.as.test.integration.ejb.mdb.cdi.MDBRAScopeCdiIntegrationTestCase.testMe(MDBRAScopeCdiIntegrationTestCase.java:228)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-800) Support file in management operation
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-800?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise reassigned WFCORE-800:
-------------------------------------------
Assignee: Jean-Francois Denise (was: Alexey Loubyansky)
> Support file in management operation
> ------------------------------------
>
> Key: WFCORE-800
> URL: https://issues.jboss.org/browse/WFCORE-800
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Alpha6
> Reporter: Jeff Mesnil
> Assignee: Jean-Francois Denise
> Labels: affects_elytron
>
> Working on WFLY-4683, I want to add 2 management operations :export-journal and :import-journal that export/import the journal from the messaging-activemq server resource.
> The :export-journal operation is similar to the :take-snapshot operation and it is acceptable that the dumped file (created internally by Artemis) is stored on the server-side in a well-know location
> However, I'd like to pass such a file to the :import-journal (specified by a dump attribute) so that the admin does not need to copy the dumped file to the server's host (or many hosts in domain mode) before calling the :import-journal operation.
> Currently, this is not doable since we can not add a stream to a management operation *from the CLI*. Instead, I have to implement a global command that will execute the client code to create the management operation, read the file and attach it to the operation as a stream.
> Ideally, I would like to specify that my :import-journal takes a dump attribute with the ModelType.FILE (or .URL ?) so that our management clients (both CLI and Web) know that they must attach the stream of the file to the management operation.
> This RFE is to simplify this use case and make it possible to use directly the CLI (and Web) console to upload files without having to create a dedicated client command for that.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-800) Support file in management operation
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-800?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise commented on WFCORE-800:
---------------------------------------------
Isn't this RFE covered by the recent support we added for stream? An int argument annotated with filesystem-path + attached-streams will be treated as a stream: File path completion + path attached as a stream to the request. Is that enough? [~jmesnil], what do you think?
> Support file in management operation
> ------------------------------------
>
> Key: WFCORE-800
> URL: https://issues.jboss.org/browse/WFCORE-800
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Alpha6
> Reporter: Jeff Mesnil
> Assignee: Alexey Loubyansky
> Labels: affects_elytron
>
> Working on WFLY-4683, I want to add 2 management operations :export-journal and :import-journal that export/import the journal from the messaging-activemq server resource.
> The :export-journal operation is similar to the :take-snapshot operation and it is acceptable that the dumped file (created internally by Artemis) is stored on the server-side in a well-know location
> However, I'd like to pass such a file to the :import-journal (specified by a dump attribute) so that the admin does not need to copy the dumped file to the server's host (or many hosts in domain mode) before calling the :import-journal operation.
> Currently, this is not doable since we can not add a stream to a management operation *from the CLI*. Instead, I have to implement a global command that will execute the client code to create the management operation, read the file and attach it to the operation as a stream.
> Ideally, I would like to specify that my :import-journal takes a dump attribute with the ModelType.FILE (or .URL ?) so that our management clients (both CLI and Web) know that they must attach the stream of the file to the management operation.
> This RFE is to simplify this use case and make it possible to use directly the CLI (and Web) console to upload files without having to create a dedicated client command for that.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-4288) error when trying to execute commands using jboss-cli.sh
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFLY-4288?page=com.atlassian.jira.plugin.... ]
Jean-Francois Denise closed WFLY-4288.
--------------------------------------
Resolution: Unresolved
> error when trying to execute commands using jboss-cli.sh
> --------------------------------------------------------
>
> Key: WFLY-4288
> URL: https://issues.jboss.org/browse/WFLY-4288
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: André Caldeira
> Assignee: Alexey Loubyansky
>
> Hi,
> I've configured jboss to use ssl, and after this change, sometimes, the command cannot be executed:
> [root@<node> ~]# /opt/oss/NSN-SQM-sqm_jboss/install/jboss-eap-6.2/bin/jboss-cli.sh --connect
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:284)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:262)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:292)
> at org.jboss.modules.Main.main(Main.java:455)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9990
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:969)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:808)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:784)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:282)
> ... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to remote://localhost:9990. The connection failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:947)
> ... 11 more
> Caused by: java.net.ConnectException: JBAS012174: Could not connect to remote://localhost:9990. The connection failed
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:160)
> at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:120)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 13 more
> Caused by: java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739)
> at org.xnio.nio.NioXnioWorker$1.handleEvent(NioXnioWorker.java:322)
> at org.xnio.nio.NioXnioWorker$1.handleEvent(NioXnioWorker.java:318)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:337)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
> ... 23 more
> In server.log what I can see when it happens is:
> 17:08:30,279 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
> 17:08:42,071 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
> 17:11:47,100 ERROR [org.jboss.remoting.remote.connection] (Remoting "<node>:MANAGEMENT" read-1) JBREM000200: Remote connection failed: java.io.IOException: Broken pipe
> this problem only happens sometimes...
> Thanks in advance,
> Br,
> André
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JGRP-2150) More efficient message adding and draining
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2150?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2150 at 1/5/17 11:36 AM:
---------------------------------------------------------
Better algorithm for a bounded MessageBatch:
{code:java}
protected final MessageBatch batch=new MessageBatch(BATCH_SIZE);
protected final AtomicInteger counter=new AtomicInteger(0);
protected void add(MessageBatch mb) {
int size=add(mb); // adds mb to this.batch
if(size > 0)
drain(size);
}
protected void drain(int num) {
if(counter.getAndAdd(num) == 0) {
final MessageBatch delivery_batch=new MessageBatch(num);
do {
delivery_batch.reset();
removed_msgs=_transfer(delivery_batch);
cnt++;
// deliver delivery_batch
} while(counter.addAndGet(-removed_msgs) != 0);
}
}
{code}
Note that counter can temporarily get negative, e.g.
* T1 adds 5 messages
* T2 adds 5 messages
* T1 increments counter from 0 -> 5, enters do-while loop
* T1 removes 10 messages, delivers the batch of 10
* T1 decrements counter by 10: -5
* T1 loops and removes 0 messages
* T2 increments counter from -5 to 0: terminates as prev_value was -5
* T1 hits the while clause which evaluates to true (counter == 0) and terminates
was (Author: belaban):
Better algorithm for a bounded MessageBatch:
{code:java}
protected final MessageBatch batch=new MessageBatch(BATCH_SIZE);
protected final AtomicInteger counter=new AtomicInteger(0);
protected void add(MessageBatch mb) {
int size=add(mb); // adds mb to this.batch
if(size > 0)
drain(size);
}
protected void drain(int num) {
if(counter.getAndAdd(num) == 0) {
final MessageBatch delivery_batch=new MessageBatch(num);
do {
delivery_batch.reset();
removed_msgs=_transfer(delivery_batch);
cnt++;
// deliver delivery_batch
} while(counter.addAndGet(-removed_msgs) != 0);
}
}
{code}
Note that counter can get nagative temporarily, e.g.
* T1 adds 5 messages
* T2 adds 5 messages
* T1 increments counter from 0 -> 5, enters do-while loop
* T1 removes 10 messages, delivers the batch of 10
* T1 decrements counter by 10: -5
* T1 loops and removes 0 messages
* T2 increments counter from -5 to 0: terminates as prev_value was -5
* T1 hits the while clause which evaluates to true (counter == 0) and terminates
> More efficient message adding and draining
> ------------------------------------------
>
> Key: JGRP-2150
> URL: https://issues.jboss.org/browse/JGRP-2150
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR1
> Fix For: 4.0
>
>
> In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where one or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
> This requires synchronization around (1) determining the thread which will remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
> Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JGRP-2150) More efficient message adding and draining
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2150?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2150 at 1/5/17 11:36 AM:
---------------------------------------------------------
Better algorithm for a bounded MessageBatch:
{code:java}
protected final MessageBatch batch=new MessageBatch(BATCH_SIZE);
protected final AtomicInteger counter=new AtomicInteger(0);
protected void add(MessageBatch mb) {
int size=add(mb); // adds mb to this.batch
if(size > 0)
drain(size);
}
protected void drain(int num) {
if(counter.getAndAdd(num) == 0) {
final MessageBatch delivery_batch=new MessageBatch(num);
do {
delivery_batch.reset();
removed_msgs=_transfer(delivery_batch);
cnt++;
// deliver delivery_batch
} while(counter.addAndGet(-removed_msgs) != 0);
}
}
{code}
Note that counter can get nagative temporarily, e.g.
* T1 adds 5 messages
* T2 adds 5 messages
* T1 increments counter from 0 -> 5, enters do-while loop
* T1 removes 10 messages, delivers the batch of 10
* T1 decrements counter by 10: -5
* T1 loops and removes 0 messages
* T2 increments counter from -5 to 0: terminates as prev_value was -5
* T1 hits the while clause which evaluates to true (counter == 0) and terminates
was (Author: belaban):
Better algorithm for a bounded MessageBatch:
{code:java}
protected final MessageBatch batch=new MessageBatch(BATCH_SIZE);
protected final AtomicInteger counter=new AtomicInteger(0);
protected void add(MessageBatch mb) {
int size=add(mb); // adds mb to this.batch
if(size > 0)
drain(size);
}
protected void drain(int num) {
if(counter.getAndAdd(num) == 0) {
final MessageBatch delivery_batch=new MessageBatch(num);
do {
delivery_batch.reset();
removed_msgs=_transfer(delivery_batch);
cnt++;
// deliver delivery_batch
} while(counter.addAndGet(-removed_msgs) != 0);
}
}
{code}
> More efficient message adding and draining
> ------------------------------------------
>
> Key: JGRP-2150
> URL: https://issues.jboss.org/browse/JGRP-2150
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR1
> Fix For: 4.0
>
>
> In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where one or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
> This requires synchronization around (1) determining the thread which will remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
> Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JGRP-2150) More efficient message adding and draining
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2150?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2150:
--------------------------------
Better algorithm for a bounded MessageBatch:
{code:java}
protected final MessageBatch batch=new MessageBatch(BATCH_SIZE);
protected final AtomicInteger counter=new AtomicInteger(0);
protected void add(MessageBatch mb) {
int size=add(mb); // adds mb to this.batch
if(size > 0)
drain(size);
}
protected void drain(int num) {
if(counter.getAndAdd(num) == 0) {
final MessageBatch delivery_batch=new MessageBatch(num);
do {
delivery_batch.reset();
removed_msgs=_transfer(delivery_batch);
cnt++;
// deliver delivery_batch
} while(counter.addAndGet(-removed_msgs) != 0);
}
}
{code}
> More efficient message adding and draining
> ------------------------------------------
>
> Key: JGRP-2150
> URL: https://issues.jboss.org/browse/JGRP-2150
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Labels: CR1
> Fix For: 4.0
>
>
> In NAKACK2, UNICAST3 and in MaxOneThreadPerSenderPolicy, we have a pattern where one or more producers add messages (to a table in NAKACK2 and UNICAST3, or to a MessageBatch in MaxOneThreadPerSenderPolicy) and then only *a single thread* can remove and deliver messages up the stack.
> This requires synchronization around (1) determining the thread which will remove messages, (2) adding messages to the table (or batch) and (3) removing messages from the table or batch.
> Unit tests DrainTest and MessageBatchDrainTest show how a simple AtomicInteger can be used to do this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-2156) CredentialReference marshalling not work with PersistentResourceXMLDescription parser
by Jan Kalina (JIRA)
Jan Kalina created WFCORE-2156:
----------------------------------
Summary: CredentialReference marshalling not work with PersistentResourceXMLDescription parser
Key: WFCORE-2156
URL: https://issues.jboss.org/browse/WFCORE-2156
Project: WildFly Core
Issue Type: Bug
Reporter: Jan Kalina
Assignee: Jan Kalina
In *org.jboss.as.controller.security.CredentialReference.credentialReferenceAttributeMarshaller()* the *marshallAsElement* method expect *credential-reference* as second param, but standard marshaller (PersistentResourceXMLDescription) puts its parent into this param.
It cause that PersistentResourceXMLDescription marshaller cannot be used for marshalling objects with CredentialReference attribute.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months