[JBoss JIRA] (WFLY-3288) Update add-user to use AESH or move it into the CLI
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3288:
----------------------------------------
For anyone looking into this, re: using the CLI for this functionality, that's fine so long as it does not create a requirement for the CLI to have access to the server filesystem. We already made that mistake with the "module" commands in the CLI.
It's even possible we could relax my constraint above re: CLI access to the server filesystem, but that will need to be done as part of general change with a broader discussion so we can iron out how to make it clear to users what the semantics are.
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFLY-3288
> URL: https://issues.jboss.org/browse/WFLY-3288
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Fix For: Awaiting Volunteers
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-3288) Update add-user to use AESH or move it into the CLI
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-3288:
--------------------------------------
Summary: Update add-user to use AESH or move it into the CLI
Key: WFLY-3288
URL: https://issues.jboss.org/browse/WFLY-3288
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Domain Management, Scripts
Reporter: Darran Lofthouse
Assignee: Brian Stansberry
Fix For: Awaiting Volunteers
Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
Switching to AESH would allow us to use the implementation there to handle this.
Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
Overall this is going to require further discussion so the comments here are just a starting point.
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-3288) Update add-user to use AESH or move it into the CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-3288:
--------------------------------------
Assignee: (was: Brian Stansberry)
> Update add-user to use AESH or move it into the CLI
> ---------------------------------------------------
>
> Key: WFLY-3288
> URL: https://issues.jboss.org/browse/WFLY-3288
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Scripts
> Reporter: Darran Lofthouse
> Fix For: Awaiting Volunteers
>
>
> Within the add-user utility it is difficult to handle situations where we do not have access to a java.io.Console which is the easiest way to handle password reading without an echo to the user e.g. in Cygwin
> Switching to AESH would allow us to use the implementation there to handle this.
> Alternatively it may actually make sense to make add-user a special mode of the CLI, we may at some point want to switch to runtime operations being executed on the server so porting to the CLI could be the first step to make this possible.
> Overall this is going to require further discussion so the comments here are just a starting point.
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-3268) Stabilize intermittently failing clustering tests
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3268?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-3268:
--------------------------------------
Ok so, closing the contexts seems pretty effective in stabilizing these.
> Stabilize intermittently failing clustering tests
> -------------------------------------------------
>
> Key: WFLY-3268
> URL: https://issues.jboss.org/browse/WFLY-3268
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 8.1.0.Final
>
>
> Some of the clustering tests
> org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulTimeoutTestCase(SYNC-tcp).timeout
> org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulFailoverTestCase(SYNC-tcp).nestedBeanFailover
> org.jboss.as.test.clustering.cluster.singleton.SingletonTestCase(SYNC-tcp).testSingletonService
> are failing due to OOM
> ERROR [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread-4) ISPN000230: Failed to start rebalance for cache default-host/stateful-failover: java.lang.OutOfMemoryError: unable to create new native thread
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-2632) JGroups drops unicast messages after shutdown/restart
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2632?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-2632:
--------------------------------------
The JGRP-1755 didn't fix the problem. We are using 3.4.3.Final now, which should have this fix included, but I still see the exceptions. Do we need a new upstream JG Jira?
> JGroups drops unicast messages after shutdown/restart
> -----------------------------------------------------
>
> Key: WFLY-2632
> URL: https://issues.jboss.org/browse/WFLY-2632
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 9.0.0.CR1
>
>
> JGroups drops unicast messages (citing wrong destination) after a node in a cluster is shutdown and then restarted.
> The JGroups version in use is 3.4.1.Final.
> Steps to reproduce:
> - start two nodes A, B using the server configuration standalone-ha.xml to create a cluster
> - shutdown A
> - restart A
> - after restart, we see these messages:
> {noformat}
> 13:15:03,227 INFO [stdout] (ServerService Thread Pool -- 63)
> 13:15:03,228 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,228 INFO [stdout] (ServerService Thread Pool -- 63) GMS: address=lenovo/web, cluster=web, physical address=127.0.0.1:55200
> 13:15:03,229 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,414 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000094: Received new cluster view: [fred/
> web|3] (2) [fred/web, lenovo/web]
> 13:15:03,422 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000079: Cache local address is lenovo/web
> , physical addresses are [127.0.0.1:55200]
> 13:15:03,427 INFO [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 63) ISPN000128: Infinispan version: Infinispan 'Infinium' 6
> .0.0.CR1
> 13:15:03,533 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:03,609 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 61) ISPN000031: MBeans were successfully registered to the platform
> MBean server.
> 13:15:03,610 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 62) ISPN000031: MBeans were successfully registered to the platform
> MBean server.
> 13:15:03,765 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 62) JBAS010281: Started default-host/distributable cache from web contain
> er
> 13:15:03,768 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 61) JBAS010281: Started dist cache from web container
> 13:15:03,906 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017534: Register web context: /distributable
> 13:15:03,978 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "distributable.war" (runtime-name : "distributable.war")
> 13:15:04,033 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:04,059 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 13:15:04,060 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 13:15:04,060 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Beta2-SNAPSHOT "WildFly" started in 5193ms - Started 293 of 410 services (178 services are lazy, passive or on-demand)
> 13:15:04,533 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,034 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,534 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> {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
10 years, 5 months
[JBoss JIRA] (JBWEB-297) NIO can improperly lead to request/response objects being used concurrently
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWEB-297?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWEB-297:
-----------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1090103|https://bugzilla.redhat.com/show_bug.cgi?id=1090103] from NEW to POST
> NIO can improperly lead to request/response objects being used concurrently
> ---------------------------------------------------------------------------
>
> Key: JBWEB-297
> URL: https://issues.jboss.org/browse/JBWEB-297
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tomcat
> Affects Versions: JBossWeb-7.2.2.GA, JBossWeb-7.3.0.GA, JBossWeb-7.4.0.GA
> Reporter: Aaron Ogburn
> Assignee: Remy Maucherat
> Attachments: JBWEB-297.diff
>
>
> Using NIO with async servlets can improperly lead to a processor and its request/response objects being used by multiple threads to process different requests at once. The problem arises here in Http11NioProtocol.event():
> {code:title=Http11NioProtocol.java|borderStyle=solid}
> public SocketState event(NioChannel channel, SocketStatus status) {
> Http11NioProcessor processor = connections.get(channel.getId());
> SocketState state = SocketState.CLOSED;
> if (processor != null) {
> processor.startProcessing();
> // Call the appropriate event
> try {
> state = processor.event(status);
> } catch (java.net.SocketException e) {
> // SocketExceptions are normal
> CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> } catch (java.io.IOException e) {
> // IOExceptions are normal
> CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> }
> // Future developers: if you discover any other
> // rare-but-nonfatal exceptions, catch them here, and log as
> // above.
> catch (Throwable e) {
> // any other exception or error is odd. Here we log it
> // with "ERROR" level, so it will show up even on
> // less-than-verbose logs.
> CoyoteLogger.HTTP_NIO_LOGGER.socketError(e);
> } finally {
> if (state != SocketState.LONG) {
> connections.remove(channel.getId());
> recycledProcessors.offer(processor);
> {code}
> If two events occur on the same channel and execute this at the same time, it'll lead to this issue if they result in a SocketState other than LONG. When that happens, they both offer the same processor to recycledProcessors in the finally block. Later on, two different requests can then poll the same processor at once from reycledProcessors; a processor should only ever have one entry in recycledProcessors.
> It looks like we need to synch the Http11NioProtocol.event() call or the NioEndpoint.ChannelProcessor.run().
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-3273) wildfly-service.exe is not working in 32 bit system-unable to start the service
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3273?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-3273.
-------------------------------
Resolution: Rejected
wildfly-service.exe is not meant to be invoked directly.
service.bat is its wrapper is needs to be used to install/uninstall/modify service registration.
after that you should use standard OS provided tools for starting / stopping services
either by services control panel item (services.msc)
or in command line by
{noformat}net start|stop wildfly{noformat}
> wildfly-service.exe is not working in 32 bit system-unable to start the service
> -------------------------------------------------------------------------------
>
> Key: WFLY-3273
> URL: https://issues.jboss.org/browse/WFLY-3273
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts, Server
> Affects Versions: 8.0.0.CR1, 8.0.0.Final
> Environment: operating system -windows 2003 server , software - JAVA, (32 BIT JDK) SERVER-WILD-FLY 8.0.0 Final
> Reporter: shaik masthan
> Assignee: Tomaz Cerar
> Labels: wildfly-windowsservice
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> i tried to register the wild-fly as a windows service using "service.bat" file (x86-32 bit system) ,successfully registered as a service and able to start up the service.
> but when i use the "wildfly-service.exe" it is register as a service but unable to start up the service , "always getting the error message "failed to start the service".
> i tried passing the command line options "--jvm,--Classpath,--JavaHome" etc while start up the service , but did not work .
> please let us know any work around for this or is it a bug in wildfly
> thanks
> masthan
--
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
10 years, 5 months