[JBoss JIRA] (WFLY-11034) Integration with grpc (high performance, open-source universal RPC framework)
by Rogerio Ferreira (Jira)
[ https://issues.redhat.com/browse/WFLY-11034?page=com.atlassian.jira.plugi... ]
Rogerio Ferreira commented on WFLY-11034:
-----------------------------------------
i I saw now, that the ideal would be to create a topic in the latest version, correct?
> Integration with grpc (high performance, open-source universal RPC framework)
> -----------------------------------------------------------------------------
>
> Key: WFLY-11034
> URL: https://issues.redhat.com/browse/WFLY-11034
> Project: WildFly
> Issue Type: Feature Request
> Components: Remoting
> Affects Versions: 14.0.0.Final
> Reporter: Brad Maxwell
> Priority: Major
>
> https://grpc.io/
> grpc should be seamlessly integrated into Wildfly as grpc support for EJB's and other EE components would make it very easy for microservices written in other languages to interact with Wildfly.
> grpc might be a good replacement candidate for corba (binary marshalling, efficiency, good community and support, modern, http/2, streaming, strong contract).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-11034) Integration with grpc (high performance, open-source universal RPC framework)
by Rogerio Ferreira (Jira)
[ https://issues.redhat.com/browse/WFLY-11034?page=com.atlassian.jira.plugi... ]
Rogerio Ferreira commented on WFLY-11034:
-----------------------------------------
Hello [~bmaxwell], the use cases we have are unary calls between microservices that require high performance. The rest api have many problems with serialization/deserialization performance. We can use runtimes WildFy if they have a support for gRPC, because in some cases the gRPC and RestAPI(servlet) need coexist in the same application..
> Integration with grpc (high performance, open-source universal RPC framework)
> -----------------------------------------------------------------------------
>
> Key: WFLY-11034
> URL: https://issues.redhat.com/browse/WFLY-11034
> Project: WildFly
> Issue Type: Feature Request
> Components: Remoting
> Affects Versions: 14.0.0.Final
> Reporter: Brad Maxwell
> Priority: Major
>
> https://grpc.io/
> grpc should be seamlessly integrated into Wildfly as grpc support for EJB's and other EE components would make it very easy for microservices written in other languages to interact with Wildfly.
> grpc might be a good replacement candidate for corba (binary marshalling, efficiency, good community and support, modern, http/2, streaming, strong contract).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13498) @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-13498?page=com.atlassian.jira.plugi... ]
Matěj Novotný edited comment on WFLY-13498 at 5/20/20 10:38 AM:
----------------------------------------------------------------
Hello [~fearghalom]
Since your archive is in the {{lib}} folder, could you try to modify the observer method payload to {{Object}}?
Like this:
{code}
private void init(@Observes @Initialized(ApplicationScoped.class) Object o) {
System.out.println("Invoking the event observer method..................");
}
{code}
According to [CDI specification|https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#applicati...], the {{@Initialized}} event can have two different payloads based on what kind of bean archive it is in.
If memory serves, your modules under {{lib}} will be treated as non-web modules and should receive the even with {{Object}} payload. Whereas your main app will be treated as web app and as such will receive payload of {{ServletContext}}.
In Weld this is done within [HttpContextLifecycle|https://github.com/weld/core/blob/3.1/modules/web/src/main/java/org/jboss/weld/module/web/servlet/HttpContextLifecycle.java#L147] for web modules and in [WeldStartup|https://github.com/weld/core/blob/3.1/impl/src/main/java/org/...] for non-web modules.
I don't recall the gory details from the top of my head, but if the suggested solution doesn't help, we can look deeper. Let me know.
was (Author: manovotn):
Hello [~fearghalom]
Since your archive is in the {{lib}} folder, could you try to modify the observer method payload to {{Object}}?
Like this:
{code}
private void init(@Observes @Initialized(ApplicationScoped.class) Object o) {
System.out.println("Invoking the event observer method..................");
}
{code}
According to [CDI specification|https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#applicati...], the {{@Initialized}} event can have two different payloads based on what kind of bean archive it is in.
> @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16
> --------------------------------------------------------------
>
> Key: WFLY-13498
> URL: https://issues.redhat.com/browse/WFLY-13498
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 16.0.0.Final
> Reporter: Fearghal O Maolcatha
> Assignee: Matěj Novotný
> Priority: Major
>
> I have an @ApplicationScoped bean that I want to be instantiated on application startup (see sample code below). I've registered for the servlet context initialization event but the init method is never invoked. The FactoryLocator is contained in a jar within my war's WEB-INF/lib directory. This same code was working on Wildfly 9 but no longer works after upgrading to Wildfly 16.
> {code:java}
> import javax.enterprise.context.ApplicationScoped;
> import javax.enterprise.context.Initialized;
> import javax.enterprise.event.Observes;
> import javax.servlet.ServletContext;
> @ApplicationScoped
> public class FactoryLocator {
> public FactoryLocator() {
> System.out.println("In the constructor.........................");
> }
> private void init(@Observes @Initialized(ApplicationScoped.class) ServletContext sc) {
> System.out.println("Invoking the event observer method..................");
> }
> }
> {code}
> One workaround I discovered was to extract the contents of the jars in my war's WEB-INF/lib/ directory to my war's WEB-INF/classes directory. When I did this my FactorLocator bean was instantiated successfully. I'd prefer not to have to do this.
> After debugging through the war's deployment, I noticed that the ServletContext is initialized before all the beans in the war's lib directory are processed (org.jboss.weld.bootstrap.BeanDeploymentModules:processBeanDeployments). The war's module is not aware of all observers until all the beans are processed. However, the ServletContextEvent is fired before all the observers are known.
> Should this happen that ServletContext is created before all observers are known about? I've debugged one of the Wildfly QuickStart applications and the ServletContext isn't created until all bean deployments are processed and the code below is executed successfully. Is the order in which this happens supposed to be guaranteed?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13498) @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-13498?page=com.atlassian.jira.plugi... ]
Matěj Novotný commented on WFLY-13498:
--------------------------------------
Hello [~fearghalom]
Since your archive is in the {{lib}} folder, could you try to modify the observer method payload to {{Object}}?
Like this:
{code}
private void init(@Observes @Initialized(ApplicationScoped.class) Object o) {
System.out.println("Invoking the event observer method..................");
}
{code}
According to [CDI specification|https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#applicati...], the {{@Initialized}} event can have two different payloads based on what kind of bean archive it is in.
> @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16
> --------------------------------------------------------------
>
> Key: WFLY-13498
> URL: https://issues.redhat.com/browse/WFLY-13498
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 16.0.0.Final
> Reporter: Fearghal O Maolcatha
> Assignee: Matěj Novotný
> Priority: Major
>
> I have an @ApplicationScoped bean that I want to be instantiated on application startup (see sample code below). I've registered for the servlet context initialization event but the init method is never invoked. The FactoryLocator is contained in a jar within my war's WEB-INF/lib directory. This same code was working on Wildfly 9 but no longer works after upgrading to Wildfly 16.
> {code:java}
> import javax.enterprise.context.ApplicationScoped;
> import javax.enterprise.context.Initialized;
> import javax.enterprise.event.Observes;
> import javax.servlet.ServletContext;
> @ApplicationScoped
> public class FactoryLocator {
> public FactoryLocator() {
> System.out.println("In the constructor.........................");
> }
> private void init(@Observes @Initialized(ApplicationScoped.class) ServletContext sc) {
> System.out.println("Invoking the event observer method..................");
> }
> }
> {code}
> One workaround I discovered was to extract the contents of the jars in my war's WEB-INF/lib/ directory to my war's WEB-INF/classes directory. When I did this my FactorLocator bean was instantiated successfully. I'd prefer not to have to do this.
> After debugging through the war's deployment, I noticed that the ServletContext is initialized before all the beans in the war's lib directory are processed (org.jboss.weld.bootstrap.BeanDeploymentModules:processBeanDeployments). The war's module is not aware of all observers until all the beans are processed. However, the ServletContextEvent is fired before all the observers are known.
> Should this happen that ServletContext is created before all observers are known about? I've debugged one of the Wildfly QuickStart applications and the ServletContext isn't created until all bean deployments are processed and the code below is executed successfully. Is the order in which this happens supposed to be guaranteed?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-4974) Test runner Server start and stop timeouts are too low
by Brian Stansberry (Jira)
Brian Stansberry created WFCORE-4974:
----------------------------------------
Summary: Test runner Server start and stop timeouts are too low
Key: WFCORE-4974
URL: https://issues.redhat.com/browse/WFCORE-4974
Project: WildFly Core
Issue Type: Task
Components: Test Suite
Reporter: Brian Stansberry
Assignee: Brian Stansberry
org.wildfly.core.testrunner.Server has a default start timeout of 30 secs and a default stop timeout of 10 secs. Too low, particularly the start timeout. An overloaded CI env or a badly timed GC shouldn't lead to test failures.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13498) @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16
by Fearghal O Maolcatha (Jira)
Fearghal O Maolcatha created WFLY-13498:
-------------------------------------------
Summary: @ApplicationScoped Bean Not Eagerly Instantiated on Wildfly 16
Key: WFLY-13498
URL: https://issues.redhat.com/browse/WFLY-13498
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 16.0.0.Final
Reporter: Fearghal O Maolcatha
Assignee: Matěj Novotný
I have an @ApplicationScoped bean that I want to be instantiated on application startup (see sample code below). I've registered for the servlet context initialization event but the init method is never invoked. The FactoryLocator is contained in a jar within my war's WEB-INF/lib directory. This same code was working on Wildfly 9 but no longer works after upgrading to Wildfly 16.
{code:java}
import javax.enterprise.context.ApplicationScoped;
import javax.enterprise.context.Initialized;
import javax.enterprise.event.Observes;
import javax.servlet.ServletContext;
@ApplicationScoped
public class FactoryLocator {
public FactoryLocator() {
System.out.println("In the constructor.........................");
}
private void init(@Observes @Initialized(ApplicationScoped.class) ServletContext sc) {
System.out.println("Invoking the event observer method..................");
}
}
{code}
One workaround I discovered was to extract the contents of the jars in my war's WEB-INF/lib/ directory to my war's WEB-INF/classes directory. When I did this my FactorLocator bean was instantiated successfully. I'd prefer not to have to do this.
After debugging through the war's deployment, I noticed that the ServletContext is initialized before all the beans in the war's lib directory are processed (org.jboss.weld.bootstrap.BeanDeploymentModules:processBeanDeployments). The war's module is not aware of all observers until all the beans are processed. However, the ServletContextEvent is fired before all the observers are known.
Should this happen that ServletContext is created before all observers are known about? I've debugged one of the Wildfly QuickStart applications and the ServletContext isn't created until all bean deployments are processed and the code below is executed successfully. Is the order in which this happens supposed to be guaranteed?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-10173) EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-10173?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-10173:
-----------------------------------
[~lvydra] any updates?
> EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
> -------------------------------------------------------------
>
> Key: WFLY-10173
> URL: https://issues.redhat.com/browse/WFLY-10173
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Final
> Reporter: Jan Kalina
> Assignee: Lukas Vydra
> Priority: Major
>
> Sometime, when running EjbInvocationStatisticsTestCase on Windows, assertion fails, as wait-time is 0 (verified it is 0 by adding debug message).
> For me it fails allTests in most of cases, but when running test standalone, it fails only in 1 of 4 cases.
> I suppose it is because of too short sleep in AbstractManagedBean. (in test is called 4 times, each invocation include 50ms sleep, so I consider probable the wait-time is 0 - need to use longer sleeps to fulfill the test)
> {code}
> [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.078 s <<< FAILURE! - in org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase
> [ERROR] testSingletonWaitTime(org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase) Time elapsed: 0.438 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.validateWaitTimeStatistic(EjbInvocationStatisticsTestCase.java:179)
> at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.testSingletonWaitTime(EjbInvocationStatisticsTestCase.java:148)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379)
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-10173) EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-10173?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-10173:
-----------------------------------
It also fails intermittently on Linux, for ex:
https://ci.wildfly.org/viewLog.html?buildId=206002&tab=buildResultsDiv&bu...
> EjbInvocationStatisticsTestCase fails on Windows: wait-time=0
> -------------------------------------------------------------
>
> Key: WFLY-10173
> URL: https://issues.redhat.com/browse/WFLY-10173
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Final
> Reporter: Jan Kalina
> Assignee: Lukas Vydra
> Priority: Major
>
> Sometime, when running EjbInvocationStatisticsTestCase on Windows, assertion fails, as wait-time is 0 (verified it is 0 by adding debug message).
> For me it fails allTests in most of cases, but when running test standalone, it fails only in 1 of 4 cases.
> I suppose it is because of too short sleep in AbstractManagedBean. (in test is called 4 times, each invocation include 50ms sleep, so I consider probable the wait-time is 0 - need to use longer sleeps to fulfill the test)
> {code}
> [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.078 s <<< FAILURE! - in org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase
> [ERROR] testSingletonWaitTime(org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase) Time elapsed: 0.438 s <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.validateWaitTimeStatistic(EjbInvocationStatisticsTestCase.java:179)
> at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.testSingletonWaitTime(EjbInvocationStatisticsTestCase.java:148)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379)
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months