[JBoss JIRA] (WFLY-2862) Liferay too many open files
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2862?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-2862:
---------------------------------
Assignee: Tomaz Cerar (was: Stuart Douglas)
> Liferay too many open files
> ---------------------------
>
> Key: WFLY-2862
> URL: https://issues.jboss.org/browse/WFLY-2862
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: linux 3.11.0-15-generic
> Reporter: Jakob Munih
> Assignee: Tomaz Cerar
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> Liferay 6.2 deploys as an exploded war. Normally after deployment it builds a theme (css/js boundles). Even if only Liferay is deployed a Too many open files exception is thrown. When /proc/sys/fs/file-max is 6815744. While trying to configure it or deploy other portlets (exploded wars too) the too many open files exception is encountered even at the deployment time (server start up).
> 13:57:48,110 ERROR [MSC service thread 1-12][MainServlet:262] java.io.FileNotFoundException: /home/munih/development/tools/wildfly-8.0.0.Final-SNAPSHOT/standalone/deployments/ROOT.war/WEB-INF/liferay-layout-templates.xml (Too many open files)
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2862) Liferay too many open files during deployment
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2862?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-2862:
------------------------------
Summary: Liferay too many open files during deployment (was: Liferay too many open files)
> Liferay too many open files during deployment
> ---------------------------------------------
>
> Key: WFLY-2862
> URL: https://issues.jboss.org/browse/WFLY-2862
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: linux 3.11.0-15-generic
> Reporter: Jakob Munih
> Assignee: Tomaz Cerar
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> Liferay 6.2 deploys as an exploded war. Normally after deployment it builds a theme (css/js boundles). Even if only Liferay is deployed a Too many open files exception is thrown. When /proc/sys/fs/file-max is 6815744. While trying to configure it or deploy other portlets (exploded wars too) the too many open files exception is encountered even at the deployment time (server start up).
> 13:57:48,110 ERROR [MSC service thread 1-12][MainServlet:262] java.io.FileNotFoundException: /home/munih/development/tools/wildfly-8.0.0.Final-SNAPSHOT/standalone/deployments/ROOT.war/WEB-INF/liferay-layout-templates.xml (Too many open files)
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2862) Liferay too many open files
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2862?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-2862:
------------------------------
Affects Version/s: 8.0.0.CR1
(was: 8.0.0.Final)
> Liferay too many open files
> ---------------------------
>
> Key: WFLY-2862
> URL: https://issues.jboss.org/browse/WFLY-2862
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: linux 3.11.0-15-generic
> Reporter: Jakob Munih
> Assignee: Stuart Douglas
>
> Liferay 6.2 deploys as an exploded war. Normally after deployment it builds a theme (css/js boundles). Even if only Liferay is deployed a Too many open files exception is thrown. When /proc/sys/fs/file-max is 6815744. While trying to configure it or deploy other portlets (exploded wars too) the too many open files exception is encountered even at the deployment time (server start up).
> 13:57:48,110 ERROR [MSC service thread 1-12][MainServlet:262] java.io.FileNotFoundException: /home/munih/development/tools/wildfly-8.0.0.Final-SNAPSHOT/standalone/deployments/ROOT.war/WEB-INF/liferay-layout-templates.xml (Too many open files)
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2862) Liferay too many open files
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2862?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-2862:
------------------------------
Fix Version/s: 8.0.0.Final
> Liferay too many open files
> ---------------------------
>
> Key: WFLY-2862
> URL: https://issues.jboss.org/browse/WFLY-2862
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: linux 3.11.0-15-generic
> Reporter: Jakob Munih
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Final
>
>
> Liferay 6.2 deploys as an exploded war. Normally after deployment it builds a theme (css/js boundles). Even if only Liferay is deployed a Too many open files exception is thrown. When /proc/sys/fs/file-max is 6815744. While trying to configure it or deploy other portlets (exploded wars too) the too many open files exception is encountered even at the deployment time (server start up).
> 13:57:48,110 ERROR [MSC service thread 1-12][MainServlet:262] java.io.FileNotFoundException: /home/munih/development/tools/wildfly-8.0.0.Final-SNAPSHOT/standalone/deployments/ROOT.war/WEB-INF/liferay-layout-templates.xml (Too many open files)
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2862) Liferay too many open files
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2862?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-2862:
------------------------------
Priority: Blocker (was: Major)
> Liferay too many open files
> ---------------------------
>
> Key: WFLY-2862
> URL: https://issues.jboss.org/browse/WFLY-2862
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.CR1
> Environment: linux 3.11.0-15-generic
> Reporter: Jakob Munih
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> Liferay 6.2 deploys as an exploded war. Normally after deployment it builds a theme (css/js boundles). Even if only Liferay is deployed a Too many open files exception is thrown. When /proc/sys/fs/file-max is 6815744. While trying to configure it or deploy other portlets (exploded wars too) the too many open files exception is encountered even at the deployment time (server start up).
> 13:57:48,110 ERROR [MSC service thread 1-12][MainServlet:262] java.io.FileNotFoundException: /home/munih/development/tools/wildfly-8.0.0.Final-SNAPSHOT/standalone/deployments/ROOT.war/WEB-INF/liferay-layout-templates.xml (Too many open files)
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2862) Liferay too many open files
by Jakob Munih (JIRA)
Jakob Munih created WFLY-2862:
---------------------------------
Summary: Liferay too many open files
Key: WFLY-2862
URL: https://issues.jboss.org/browse/WFLY-2862
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.0.0.Final
Environment: linux 3.11.0-15-generic
Reporter: Jakob Munih
Assignee: Stuart Douglas
Liferay 6.2 deploys as an exploded war. Normally after deployment it builds a theme (css/js boundles). Even if only Liferay is deployed a Too many open files exception is thrown. When /proc/sys/fs/file-max is 6815744. While trying to configure it or deploy other portlets (exploded wars too) the too many open files exception is encountered even at the deployment time (server start up).
13:57:48,110 ERROR [MSC service thread 1-12][MainServlet:262] java.io.FileNotFoundException: /home/munih/development/tools/wildfly-8.0.0.Final-SNAPSHOT/standalone/deployments/ROOT.war/WEB-INF/liferay-layout-templates.xml (Too many open files)
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2161) JBAS014356 exception not thrown for @Asyncronous EJB methods
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2161?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2161:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1060734|https://bugzilla.redhat.com/show_bug.cgi?id=1060734] from POST to MODIFIED
> JBAS014356 exception not thrown for @Asyncronous EJB methods
> ------------------------------------------------------------
>
> Key: WFLY-2161
> URL: https://issues.jboss.org/browse/WFLY-2161
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Alpha4
> Reporter: James Livingston
> Assignee: Stuart Douglas
> Fix For: 8.0.0.CR1
>
>
> If you call an ejb method with default visibility (e.g. from a servlet in the same package), an EJBException with code JBAS014356 is thrown because the method is not public.
> If the method is annotated with @Asynchronous and returns void, the exception is not seen because the interceptor from AsyncFutureInterceptorFactory is used before NotBusinessMethodInterceptor, the exception is thrown in the worker thread instead.
> With a void return, the exception is silently dropped. With a Future<?> return, it will be set as the failure exception on the future rather than being thrown from the call.
> As per the forum reference we need to check the spec, but the validity of the business method should probably be checked before the handoff to the worker 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
12 years, 3 months
[JBoss JIRA] (WFLY-2851) Can't validate jboss-deployment-structure.xml due to incorrect schema
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2851?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2851:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1060719|https://bugzilla.redhat.com/show_bug.cgi?id=1060719] from POST to MODIFIED
> Can't validate jboss-deployment-structure.xml due to incorrect schema
> ---------------------------------------------------------------------
>
> Key: WFLY-2851
> URL: https://issues.jboss.org/browse/WFLY-2851
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.CR1
> Reporter: Harald Wellmann
> Assignee: Stuart Douglas
>
> The following deployment structure cannot be validated against the XML schema:
> {code:xml}
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <dependencies>
> <module name="foo"/>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
> This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.
> The same holds for the {{filter}} element of {{resource-root}}, which should be optional according to the schema documentation.
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2319) LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2319?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-2319:
----------------------------------------
This was resolved against a release - it should not be re-opened.
> LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2319
> URL: https://issues.jboss.org/browse/WFLY-2319
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Naming
> Affects Versions: 8.0.0.Beta1
> Reporter: Darran Lofthouse
> Assignee: Eduardo Martins
> Fix For: 8.0.0.CR1
>
> Attachments: LdapSearching.tgz
>
>
> The following code: -
> {code}
> Hashtable env = new Hashtable();
> env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
> env.put("java.naming.security.authentication", "simple");
> env.put("java.naming.provider.url", "ldap://localhost:10389");
> env.put(InitialDirContext.SECURITY_PRINCIPAL, "uid=admin,ou=system");
> env.put(InitialDirContext.SECURITY_CREDENTIALS, "secret");
> SearchControls ctl = null;
> String attrArr[] = new String[1];
> attrArr[0] = "sn";
> ctl = new SearchControls(2, 0L, 0, attrArr, false, false);
> String base = "ldap://localhost:10389/dc=simple,dc=wildfly,dc=org";
> String filter = "(uid=UserOne)";
> NamingEnumeration nenum = null;
> DirContext ictx = null;
> ictx = new InitialDirContext(env);
> nenum = ictx.search(base, filter, ctl);
> {code}
> Results in the following exception: -
> {noquote}
> 13:03:45,598 ERROR [stderr] (default task-1) javax.naming.InvalidNameException: ldap:: [LDAP: error code 34 - Invalid root Dn given : ldap: (0x6C 0x64 0x61 0x70 0x3A ) is invalid]; remaining name 'ldap://localhost:10389/dc=simple,dc=wildfly,dc=org'
> 13:03:45,599 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3025)
> 13:03:45,600 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840)
> 13:03:45,600 ERROR [stderr] (default task-1) at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1034)
> {noquote}
> Switching to a base that does not begin with a URL and the search works, executing this code outside of WildFly also works.
> The underlying issue is that the default InitialContext implementation contains the following method: -
> {code}
> protected Context getURLOrDefaultInitCtx(String name)
> throws NamingException {
> if (NamingManager.hasInitialContextFactoryBuilder()) {
> return getDefaultInitCtx();
> }
> String scheme = getURLScheme(name);
> if (scheme != null) {
> Context ctx = NamingManager.getURLContext(scheme, myProps);
> if (ctx != null) {
> return ctx;
> }
> }
> return getDefaultInitCtx();
> }
> {code}
> As the naming subsystem has registered a InitialContextFactoryBuilder this code will never fall down to the scheme specific section.
--
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
12 years, 3 months