[JBoss JIRA] (WFLY-4743) Unable to start server on Windows from path containing special characters jboss-eap-ŽlutýKůň-7.0
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4743?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski closed WFLY-4743.
------------------------------------
Resolution: Won't Fix
> Unable to start server on Windows from path containing special characters jboss-eap-ŽlutýKůň-7.0
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4743
> URL: https://issues.jboss.org/browse/WFLY-4743
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 10.0.0.Alpha2
> Reporter: Marek Kopecký
> Assignee: Bartosz Baranowski
>
> *Description of problem:*
> Server is unable to start if JBOSS_HOME contaings "ŽlutýKůň" characters. This issue is valid for standalone and domain.
> *How reproducible:*
> Windows
> *Steps to Reproduce:*
> * standalone.bat
> * standalone.ps1
> *Actual results:*
> {noformat}
> ....
> Error: Unable to access jarfile C:\Users\Administrator\7.0.0.DR3\jboss-eap-Älut²Kun\jboss-modules.jar
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4743) Unable to start server on Windows from path containing special characters jboss-eap-ŽlutýKůň-7.0
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4743?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski reassigned WFLY-4743:
----------------------------------------
Assignee: Bartosz Baranowski (was: Tomaz Cerar)
> Unable to start server on Windows from path containing special characters jboss-eap-ŽlutýKůň-7.0
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4743
> URL: https://issues.jboss.org/browse/WFLY-4743
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 10.0.0.Alpha2
> Reporter: Marek Kopecký
> Assignee: Bartosz Baranowski
>
> *Description of problem:*
> Server is unable to start if JBOSS_HOME contaings "ŽlutýKůň" characters. This issue is valid for standalone and domain.
> *How reproducible:*
> Windows
> *Steps to Reproduce:*
> * standalone.bat
> * standalone.ps1
> *Actual results:*
> {noformat}
> ....
> Error: Unable to access jarfile C:\Users\Administrator\7.0.0.DR3\jboss-eap-Älut²Kun\jboss-modules.jar
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4827) Network Connection leak on client abort connection
by Andrea Bertolini (JIRA)
Andrea Bertolini created WFLY-4827:
--------------------------------------
Summary: Network Connection leak on client abort connection
Key: WFLY-4827
URL: https://issues.jboss.org/browse/WFLY-4827
Project: WildFly
Issue Type: Bug
Components: Web (Undertow), Web Sockets
Affects Versions: 8.2.0.Final
Environment: On Windows Server 2012, JDK 1.8.0_45, Wildfly 8.2.0.Final in standalone mode.
Reporter: Andrea Bertolini
Assignee: Stuart Douglas
We have a classic client-server application, all written in Java. Each client is installed on a forklift which can move all around a large area. This area is under wi-fi coverage.
Sometimes the clients can have a bad connection quality and the client-server communication is interrupted; in such a case it takes too many seconds to be restored.
To fix this situation, we add a timeout client-side. After 5 seconds it aborts the call and tries again a second time.
To achieve this call we use apache httpcomponents library (version 4.4). We use the abort method of httppost to interrupt this call.
Server-side, we have a group of web-servlets which listen to the incoming calls, manage requests and send a response.
It appears that sometimes a communication remains stuck in reading or writing from/to the stream. When the client aborts the communication, an exception is thrown on the server caused by the channel being closed.
It happens that a large number of connections remains stuck in connection status 'established' (only server-side) even if the real connection is actually closed (client doesn't have that connection active anymore).
When the number of established connections grows up to 200, server stops responding on port 8080, so it cannot accept more connections and it seems to freeze.
We tried to add tcp-keep-alive=true and no-request-timeout=120000 on http-listener in undertow subsystem, but sometimes it removes idle connections after any incoming requests are received for 2 minutes, some other times it keep connections as established and doesn't close them.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (ELY-20) Where does OTP fit into realms?
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-20?page=com.atlassian.jira.plugin.sys... ]
Farah Juma reassigned ELY-20:
-----------------------------
Assignee: Farah Juma (was: Darran Lofthouse)
> Where does OTP fit into realms?
> -------------------------------
>
> Key: ELY-20
> URL: https://issues.jboss.org/browse/ELY-20
> Project: WildFly Elytron
> Issue Type: Sub-task
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Fix For: 1.0.0.Beta1
>
>
> Will investigate further once we have a pure LDAP impl in.
> We could have an architecture where we have an LDAP server that is then referenced by an OTP server or we could have the two somehow combined into one.
> There are also requirements related to marking a token as used or token invalidation after too many bad attempts - this may be handled within the OTP server but for stronger authentication mechanisms may need to be more involved otherwise this becomes another case of falling back to PLAIN / BASIC auth.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFCORE-750) Capability requirement resolution for socket-bindings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-750?page=com.atlassian.jira.plugin... ]
Brian Stansberry reopened WFCORE-750:
-------------------------------------
Reopening as I realize the existing work doesn't deal properly with includes.
An included profile or s-b-g needs to be treated as if it were a part of the including profile/s-b-g's CapabilityContext. Otherwise a requirer in context "profile-includer" will not be able to find capabilities in profile "profile-included". And if a profile is mapped to a server-group along with "s-b-g-includer", and requirers in that profile need sockets from "s-b-g-includer" and "s-b-g-includee" that will be treated as an incompatible mapping, since the fact "s-b-g-includer" includes "s-b-g-includee" is not understood.
> Capability requirement resolution for socket-bindings
> -----------------------------------------------------
>
> Key: WFCORE-750
> URL: https://issues.jboss.org/browse/WFCORE-750
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.Alpha5
>
>
> In a managed domain the existing capability resolution mechanism will not work properly for socket binding capabilities due to the relationship between socket-binding-groups and profiles.
> The same socket-binding capability name can be registered in different socket-binding-groups. The existing approach can handle this easily enough by creating a CapabilityContext for each group, a la what is down with profiles. But then the resolution of requirements from resources in profiles needs to be handled.
> The particular thing is that *all* requirements for socket bindings within a given profile must be resolvable against at least one socket binding group. Otherwise, no server group can map that profile and a socket binding group and end up with a combination that will work on a server.
> So, the capability requirement validation stuff will need a consistency check for this case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFCORE-750) Capability requirement resolution for socket-bindings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-750?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-750:
------------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 2.0.0.Alpha5)
> Capability requirement resolution for socket-bindings
> -----------------------------------------------------
>
> Key: WFCORE-750
> URL: https://issues.jboss.org/browse/WFCORE-750
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.Beta1
>
>
> In a managed domain the existing capability resolution mechanism will not work properly for socket binding capabilities due to the relationship between socket-binding-groups and profiles.
> The same socket-binding capability name can be registered in different socket-binding-groups. The existing approach can handle this easily enough by creating a CapabilityContext for each group, a la what is down with profiles. But then the resolution of requirements from resources in profiles needs to be handled.
> The particular thing is that *all* requirements for socket bindings within a given profile must be resolvable against at least one socket binding group. Otherwise, no server group can map that profile and a socket binding group and end up with a combination that will work on a server.
> So, the capability requirement validation stuff will need a consistency check for this case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4737) Unable to start EAP if JBOSS_HOME ends with exclamation mark
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4737?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski closed WFLY-4737.
------------------------------------
Resolution: Won't Fix
> Unable to start EAP if JBOSS_HOME ends with exclamation mark
> -------------------------------------------------------------
>
> Key: WFLY-4737
> URL: https://issues.jboss.org/browse/WFLY-4737
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 10.0.0.Alpha1
> Reporter: Marek Kopecký
> Assignee: Bartosz Baranowski
>
> *Description of problem:*
> EAP is unable to start if JBOSS_HOME ends with exclamation mark. This issue is valid for standalone and domain.
> *How reproducible:*
> Windows, RHEL, HPUX, Solaris
> *Steps to Reproduce:*
> # \[mkopecky@localhost jboss-eap-7.0!\]$ ./bin/standalone.sh
> *Actual results:*
> {noformat}
> ....
> 15:44:35,479 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.as: org.jboss.msc.service.StartException in service jboss.as: Failed to start service
> .....
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFLY-4737) Unable to start EAP if JBOSS_HOME ends with exclamation mark
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4737?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski reassigned WFLY-4737:
----------------------------------------
Assignee: Bartosz Baranowski (was: James Perkins)
> Unable to start EAP if JBOSS_HOME ends with exclamation mark
> -------------------------------------------------------------
>
> Key: WFLY-4737
> URL: https://issues.jboss.org/browse/WFLY-4737
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 10.0.0.Alpha1
> Reporter: Marek Kopecký
> Assignee: Bartosz Baranowski
>
> *Description of problem:*
> EAP is unable to start if JBOSS_HOME ends with exclamation mark. This issue is valid for standalone and domain.
> *How reproducible:*
> Windows, RHEL, HPUX, Solaris
> *Steps to Reproduce:*
> # \[mkopecky@localhost jboss-eap-7.0!\]$ ./bin/standalone.sh
> *Actual results:*
> {noformat}
> ....
> 15:44:35,479 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.as: org.jboss.msc.service.StartException in service jboss.as: Failed to start service
> .....
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years
[JBoss JIRA] (WFCORE-777) Add ability to use socket binding groups from host subsystems
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-777?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-777:
-----------------------------------------
The basic WFCORE-750 work is in (capability/requirement resolution for socket-binding) but it will probably need a tweak for this use case.
I forget how HC subsystems work. Is it basically analogous to a standalone server? No multiple profiles, no profile includes? And then there'd be a single set of socket bindings as well?
If so I think that means there'll need to be a single special CapabilityContext for the HC subsystems and s-b-g. Can resolve required capabilities in that context or in GLOBAL. Can't resolve from any of the domain level profile and s-b-g contexts, which are used for creating server configs.
> Add ability to use socket binding groups from host subsystems
> -------------------------------------------------------------
>
> Key: WFCORE-777
> URL: https://issues.jboss.org/browse/WFCORE-777
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
> Fix For: 2.0.0.Alpha5
>
>
> Add a single socket-binding group to host model and xml so that HC subsystems can reference those (similar to what happens on a standalone server).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years