Clustered CDI Event bug in payara micro?

[Harry Chan]

I was following this example to try the clustered CDI event on payara micro. However, I found something strange to me.

I am wondering if it is a bug, below are the reproduce steps:

1. unzip the attached project
2. cd to the clustered-cdi-event-bug folder
   
3. start 3 instances by execute the following command
   
   mvn clean package
4. after ALL instances are started
5. execute
   
   curl http://localhost:8080/clustered-cdi-event-bug/?msg=clustered-msg
   
   or enter http://localhost:8080/clustered-cdi-event-bug/?msg=clustered-msg in the address bar of your browser
   
6. check the console of ALL instances
   

Expected Result:

• the sender instance would show this message in the log
  
  Feb 12, 2017 10:22:06 PM demo.rest.TestResource fireClusteredEvent

  INFO: message: clustered-msg

  Feb 12, 2017 10:22:06 PM demo.service.EventService fireEvent

  INFO: message to be fired: clustered-msg
• ALL instance in the cluster received the cdi event, e.g: you would see the log message like
  
  Feb 12, 2017 10:22:06 PM demo.service.EventService observeEvent

  INFO: message received: MyMessage(msg=clustered-msg)

Actual Result:

• fire event log could be found in the sender instance
• sender instance does NOT show the log about receiving the CDI event

In the comment of the tutorial Steve mentioned that 

internally we are using a Hazelcast distributed topic.

And I tried to read the source code and it does using a topic. 

So if it is a topic, ALL the subscribers should be able to receive the message. If yes, there should be a bug inside.

Please correct me if I go wrong.

Thank you.

[l33t j4v4]

By default the sender does not receive the message it sent.

You can add the attribute loopback=true to your @Outbound annotation if you want the sender to receive the message.

[Ondrej Mihályi]

Hi Harry,

The behavior of CDI event bus is as described be l33t j4v4 - the events are delivered only to observers in other instance. This is intentional - the event is ignored by the local instance even if it is delivered by Hazelcast. Therefore, it requires at least 2 instances in the cluster to test the behavior.

However, we are adding loopback option in version 171, which will be released very soon. With this option set to true, the event will be delivered also to observers in the local instance. Please be patient, the next release will be announced in the following days, together with the updated documentation.

All the best,

Ondrej

[Harry Chan]

Thanks!

I will wait and try it after 171 is released

[Ondrej Mihályi]

Hi,

The version 171 has been released a while ago.

Here is documentation about the new features of the CDI event bus (including the loopback option): https://payara.gitbooks.io/payara-server/content/documentation/extended-documentation/cdi-events.html 

We'll be happy to hear back about your experience from testing out CDI event bus features.

Ondrej

[Harry Chan]

Thanks Ondrej, I will check it.

[Harry Chan]

Tested that the "loopBack" achieve what I want.

Thank you very much.

[taymindis]

Where is the loop back option? It still undefined symbol??

[taymindis]

the payara-micro 171 jar has not outbound class, compare to 164. .171 only 68mb but 164 has 143mb

[Harry Chan]

Hi Taymindis,

Please check the link provided by Ondrej for more details of the "loopback" of the remote CDI event - https://payara.gitbooks.io/payara-server/content/documentation/extended-documentation/cdi-events.html 

Best Regards,

Harry Chan

[taymindis]

I double checked the link, they said loopback option available on version 171? Am I wrong? But it does not exist from maven repos i can't build with loopBack option. 

Normal fire event is Working fine. 

[Harry Chan]

r...

I think you can't find the @Outbound annotation, right?

In 171, we need to declare the "payara-api" dependency

<dependency>

    <groupId>fish.payara.extras</groupId>

    <artifactId>payara-micro</artifactId>

    <version>${payara.version}</version>

    <scope>provided</scope>

</dependency>

<dependency>

    <groupId>fish.payara.api</groupId>

    <artifactId>payara-api</artifactId>

    <version>${payara-api.version}</version>

    <scope>provided</scope>

</dependency>

and it does NOT mentioned in the Payara Gitbook.

[taymindis]

Hi Harry, 

This is no where i can find but here. @@

you should pull request to payara git.

Thanks!

[Harry Chan]

Hi Taymindis,

Actually there is an update of the Payara "Public API" part which could be found in https://github.com/payara/Payara-Server-Documentation/blob/next/documentation/extended-documentation/app-deployment/public-api.md

And, in the URL above, you could see that it is still in the "next" branch so that it is NOT yet displayed on the GitBook until the Payara team to make the 171 branch or shift the "next" branch to the "master" branch.

I don't know when they would do it BUT I hope they could make it as soon as possible to make the doc sync with the latest release :)

Thank you.

[taymindis]

Hi Harry, 

Noted, 

But now I am getting this error:- 

Getting Exception when build deploy to payara 171

org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type PayaraMicroRuntime with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject fish.payara.examples.payaramicro.event.sender.SendEventServlet.runtime
at fish.payara.examples.payaramicro.event.sender.SendEventServlet.runtime(SendEventServlet.java:0)

at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:355)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:277)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:130)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:151)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:494)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:480)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:455)
at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:454)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:227)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:329)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:220)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:487)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at com.sun.enterprise.admin.cli.embeddable.DeployerImpl.deploy(DeployerImpl.java:134)
at fish.payara.micro.impl.PayaraMicroImpl.deployAll(PayaraMicroImpl.java:1333)
at fish.payara.micro.impl.PayaraMicroImpl.bootStrap(PayaraMicroImpl.java:1005)
at fish.payara.micro.impl.PayaraMicroImpl.main(PayaraMicroImpl.java:201)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at fish.payara.micro.boot.loader.MainMethodRunner.run(MainMethodRunner.java:48)
at fish.payara.micro.boot.loader.Launcher.launch(Launcher.java:107)
at fish.payara.micro.boot.loader.Launcher.launch(Launcher.java:70)
at fish.payara.micro.boot.PayaraMicroLauncher.main(PayaraMicroLauncher.java:72)
at fish.payara.micro.PayaraMicro.main(PayaraMicro.java:358)

[Harry Chan]

Could you provide more details such as how do you start it?

[taymindis]

I just download the latest Payara cdi-cluster example, modifiy the payara version to 4.1.171.0.1 and payara api to 4.1.172-snapshot

And successfully package and run the ClusterDeployExample. Receiver is working. But sender throwing this error.

And i also try java -jar payara-micro.jar --deploy sender.war and --deploy receiver.war. 

Having the same issue

[taymindis]

Hi Harry, I think i understand why yours is working but mine is not working. I am still running  2 instance but yours is only one.

What I expected is loopBack should be able to loop the message back to self hosting server layer.

For example

xxx.xxx.xxx.10 :8080

xxx.xxx.xxx.10 :8081

xxx.xxx.xxx.11 :8080

xxx.xxx.xxx.11 :8081

Then it should be able to communicate own segment layer.

[Harry Chan]

I am sorry that I do not get you. I just create the example in Payara Micro 171, maybe it would be helpful to you.

https://github.com/hei1233212000/payara-micro-remote-cdi-event-demo

Thanks.

[Steve Millidge]

Hi Harry,

Thanks for the example looks good.

A quick not, in 171 you shouldn't need the class https://github.com/hei1233212000/payara-micro-remote-cdi-event-demo/blob/master/src/main/java/demo/config/ClusteredCdiEventInitializer.java as t does this internally now.

Steve

[Harry Chan]

Hi Steve,

Thank you for your reminder, I just removed from the example I posted. :D

[taymindis]

Hi Harry/Steve, 

This is a good example. 

But What my purpose is, i want to treat this like a Queue with 2 instance clustered with active/backup, or (2 active with JCache, but so far not yet seen in micro), 

So it can receive from other instance and send to other instance by using eventName. Or loopBack if it is internal transaction.It can be treated as a route or filtering.

However, I believe payara-micro will be more and more interesting.

Thanks,

Taymindis

[taymindis]

Hi Harry/Steve,

Thanks. I finally make it work with removing PayaraMicroRuntime Injection. Hope it is solved soon.