Questions asked by vagabond

Signal wildcards behave in an unexpected way

vagabond — Tue, 14 May 2019 10:30:00 -0400

Hi Axon.ivy Team,

I'm using Axon.ivy LTS 7.0.8 and I'm getting an issue related to Signal.

I have 4 signal receivers:

one
one:two
one:two:three
one:two:three:four

When I send the signal one:two:three:four, I expect that only the (4) receiver would be triggered. Unfortunately, I was surprised that all four of them were triggered.

According to the official document, I would expect that only if I use the wildcard in the pattern of the Receiver, I will have the same behaviours (one:*, one:two:*, one:two:three:*) but in this case, the wildcard does not matter much here.

Is it a bug or by design that the Signal Receivers behave like that?

Thanks! Jack

Delayed Task and Expiry Tasks timing is not correct if the interval is smaller 60 seconds

vagabond — Mon, 25 Mar 2019 06:31:06 -0400

Hi Axon.ivy Team,

In our project, we have several use cases that we would like to use the Delayed Tasks or Expiry Tasks. Depends on the business needs, our delayed or expiration duration may be 30 seconds or less.

However, we discovered that the duration does not work if it is smaller than 60 seconds. I had done our homework a little bit and discovered that the WorkflowJob which was the main module used to resolve expired or delayed tasks is scheduled to run periodically on every 60 seconds. This was done in WorkflowManager.

I assumed this was done by design but it took me by surprise because I could not find anywhere mentioning this limitation. The interval, 60 seconds, is hardcoded and is not configurable like the SystemTask.SearchJob.Interval.

Is there any recommended ways to overcome this limitation?

UPDATE

In our system, we want to communicate to a 3rd party system, namely ABC, via its RESTful API.

The process starts when a User triggers a designated action on the UI. We then call the ABC's API to initiate a process on their system.
Our system then have to poll ABC's API for result asynchronously.
The ABC API requires that we have to poll for result at least after 30 seconds from the time the first request has been sent.
We want to have at max 3 attempts to call ABC's API for checking the result. Each time will have an additional delay of 10 seconds.
At the same time, the User UI may be also polling for the result. It is not required that they have to keep the UI open.

Having the above requirements, we are using Signal to trigger the polling to ABC's API asynchronously. The Signal process makes uses of SYSTEM TaskElement whose DelayDuration set to 30S. For triggering a retry, the process itself then send a new Signal with an additional delay duration.

What would be your suggestion to implement such a use case then?

Bump this up!

Regard

Jack

There is a 1-second latency between ivy.repo.save(object) and ivy.repo.search(Object.class)

vagabond — Fri, 22 Feb 2019 01:16:25 -0500

Hi Axon.ivy Team,

Given the snippet of code:

Person p = new Person();
p.id = UUID.randomUUID().toString();
p.name = "John Doe";
p.birthdate = LocalDate.now();

ivy.repo.save(p);

Object result = ivy.repo.search(Person.class)
    .textField("id").containsPhrase(p.id)
    .execute().getFirst();

ivy.log.error("HHH - it is null " + #result);

Thread.sleep(TimeUnit.SECONDS.toMillis(1));

result = ivy.repo.search(Person.class)
    .textField("id").containsPhrase(p.id)
    .execute().getFirst();

ivy.log.error("HHH - it is null " + #result);

I found that there was a 1-second latency between the call to ivy.repo.save() and ivy.repo.search(). This is super annoying because we had to wait for 1-second every time until the saved object can be searched via the API. Blocking the execution for 1-second to wait until it is indexed to ES every time we save the object into the BusinessDataRepository is a terrible hack.

Is it by design? Can this be fixed so that the two calls work?

P.S: Please don't advise me to use the returned BusinessData id because it doesn't address my issue. I want to search back the data I save based on the object's field, not fetching it again.

P.P.S: Tested with Axon.ivy Designer 7.2.1 on my local workstation.

UPDATE

25.2.2019:

In our project, we were able to develop RESTful API for other parties. As we already have persisted our objects (for example Dossier), in BusinessDataRespository, we would want to preserve that behavior.

An excerpt from of our OpenAPI spec:

paths:
  /dossiers/{dossier_id}/persons/:
    post:
     operationId: addPersonToDossier
      description: add a single person into an existing Dossier
      requestbody:
        'application/json':
          schema:
            $ref: '#/components/schemas/Person'
      responses:
        '201':

    get:
      operationId: getAllPersonsInDossier
      description: get *all* existing persons of an existing Dossier
      responses:
        '200':
          content:
            'application/json':
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Person'

From our client, after they have already invoked several calls to addPersonToDossier, they may want to invoke getAllPersonsInDossier to fetch all Persons of a Dossier.

We persists Person separately from our Dossier to avoid ConcurrentModificationException, each Person holds a reference to its Dossier. Now in order to implement getAllPersonsInDossier, we have to use Ivy.repo().search(..).

Unfortunately, due to the 1-second latency, calling getAllPersonsInDossier too soon will probably return an empty result. This forces us to either:

Require our clients to WAIT on their side for 1-second until they can call getAllPersonsInDossier.
On the server side, we somehow have to implement a while loop to check until the Person could be found via search API, then we consider the addPersonToDossier finishes (or worse, a Thread.sleep(1000)).

Jack

Cannot use BusinessDataRepository in JAX-RS resources

vagabond — Thu, 24 Jan 2019 00:49:27 -0500

Hi Axon.ivy team,

I know this questions had been asked long time ago at https://answers.axonivy.com/questions/2777/can-not-use-ivy-repo-in-resfulapi. But the question was for Axon.ivy 6.3.0 and there was never a resolution of the issue.

I am using Axon.ivy 7.0.8 LTS and I still encountered the same issue.

I introduce a JAX-RS resource:

package com.example.lab;

@PermitAll
@Path("awesome")
public class TheAwesomeApi {

    @POST
    @Consume("application/json")
    @Produces("text/plain")
    public String saveAwesomeMessage(AwesomeMessage message) {
        return Ivy.repo().save(message).getId();
    }

    public static class AwesomeMessage {
        private String content;
        // getter, setter
    }
}

When I tried to call this API, the exception was returned.

curl http://localhost:8081/ivy/api/designer/awesome \
  -H 'Content-Type: application/json' \
  -d '{ "content" : "This is an awesome message" }'

full stacktrace can be found here: https://pastebin.com/hXcyQq6h

Unable to provision, see the following errors:

1) Error in custom provider, java.lang.NullPointerException
  while locating ch.ivyteam.ivy.scripting.dataclass.internal.di.IvyCaseProjectClassLoaderProvider
  while locating java.lang.ClassLoader annotated with interface ch.ivyteam.ivy.scope.restricted.FromCaseScope
Caused by: java.lang.NullPointerException
    at ch.ivyteam.ivy.scripting.dataclass.internal.di.IvyCaseProjectClassLoaderProvider.get(IvyCaseProjectClassLoaderProvider.java:20)
    at ch.ivyteam.ivy.scripting.dataclass.internal.di.IvyCaseProjectClassLoaderProvider.get(IvyCaseProjectClassLoaderProvider.java:1)
    at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
    at com.google.inject.internal.BoundProviderFactory.provision(BoundProviderFactory.java:72)
    at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:61)
    at com.google.inject.internal.BoundProviderFactory.get(BoundProviderFactory.java:62)
    at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1019)
    at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1085)
    at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1015)
    at ch.ivyteam.ivy.business.data.store.restricted.BusinessDataTypeLoader.getContextClassLoader(BusinessDataTypeLoader.java:60)
    at ch.ivyteam.ivy.business.data.store.internal.BusinessDataRepositoryImpl.serialize(BusinessDataRepositoryImpl.java:369)
    at ch.ivyteam.ivy.business.data.store.internal.BusinessDataRepositoryImpl.lambda$0(BusinessDataRepositoryImpl.java:196)
    at ch.ivyteam.ivy.business.data.store.internal.ElasticSystemDbPersistence.lambda$14(ElasticSystemDbPersistence.java:439)
    at ch.ivyteam.ivy.persistence.base.AbstractPersistencyService.execute(AbstractPersistencyService.java:177)
    at ch.ivyteam.ivy.persistence.base.ClassPersistencyService.execute(ClassPersistencyService.java:673)
    at ch.ivyteam.ivy.business.data.store.internal.ElasticSystemDbPersistence.executeInTransaction(ElasticSystemDbPersistence.java:435)
    at ch.ivyteam.ivy.business.data.store.internal.BusinessDataRepositoryImpl.create(BusinessDataRepositoryImpl.java:194)
    at ch.ivyteam.ivy.business.data.store.internal.BusinessDataRepositoryImpl.save(BusinessDataRepositoryImpl.java:177)
    at com.example.lab.axonivy.api.TheAwesomeApi.saveAwesomeMessage(TheAwesomeApi.java:35)
    ....
    at java.lang.Thread.run(Thread.java:748)

2) Error in custom provider, com.google.inject.OutOfScopeException: No case available in the current scope/context
  while locating ch.ivyteam.ivy.workflow.internal.di.CaseProvider
  while locating ch.ivyteam.ivy.workflow.ICase
    for field at ch.ivyteam.ivy.scripting.dataclass.internal.di.IvyCaseProjectClassLoaderProvider.caze(IvyCaseProjectClassLoaderProvider.java:1)
  while locating ch.ivyteam.ivy.scripting.dataclass.internal.di.IvyCaseProjectClassLoaderProvider
  while locating java.lang.ClassLoader annotated with interface ch.ivyteam.ivy.scope.restricted.FromCaseScope
Caused by: com.google.inject.OutOfScopeException: No case available in the current scope/context
    at ch.ivyteam.ivy.workflow.internal.di.CaseProvider.get(CaseProvider.java:24)
    at ch.ivyteam.ivy.workflow.internal.di.CaseProvider.get(CaseProvider.java:1)
    at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
    at com.google.inject.internal.ProvidedByInternalFactory.provision(ProvidedByInternalFactory.java:82)
    at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:61)
    at com.google.inject.internal.ProvidedByInternalFactory.get(ProvidedByInternalFactory.java:71)
    at com.google.inject.internal.SingleFieldInjector.inject(SingleFieldInjector.java:54)
    at com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:132)
    at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:120)
    at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:90)
    at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:268)
    at com.google.inject.internal.BoundProviderFactory.get(BoundProviderFactory.java:61)
    at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1019)
    at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1085)
    at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1015)
    at ch.ivyteam.ivy.business.data.store.restricted.BusinessDataTypeLoader.getContextClassLoader(BusinessDataTypeLoader.java:60)
    at ch.ivyteam.ivy.business.data.store.internal.BusinessDataRepositoryImpl.serialize(BusinessDataRepositoryImpl.java:369)
    at ch.ivyteam.ivy.business.data.store.internal.BusinessDataRepositoryImpl.lambda$0(BusinessDataRepositoryImpl.java:196)
    at ch.ivyteam.ivy.business.data.store.internal.ElasticSystemDbPersistence.lambda$14(ElasticSystemDbPersistence.java:439)
    at ch.ivyteam.ivy.persistence.base.AbstractPersistencyService.execute(AbstractPersistencyService.java:177)
    at ch.ivyteam.ivy.persistence.base.ClassPersistencyService.execute(ClassPersistencyService.java:673)
    at ch.ivyteam.ivy.business.data.store.internal.ElasticSystemDbPersistence.executeInTransaction(ElasticSystemDbPersistence.java:435)
    at ch.ivyteam.ivy.business.data.store.internal.BusinessDataRepositoryImpl.create(BusinessDataRepositoryImpl.java:194)
    at ch.ivyteam.ivy.business.data.store.internal.BusinessDataRepositoryImpl.save(BusinessDataRepositoryImpl.java:177)
    at com.example.lab.axonivy.api.TheAwesomeApi.saveAwesomeMessage(TheAwesomeApi.java:35)
    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 ch.ivyteam.ivy.webserver.internal.rest.resource.project.RestPmvInvocationHandler$PmvAwareInvocator.lambda$0(RestPmvInvocationHandler.java:38)
    at ch.ivyteam.ivy.webserver.internal.rest.resource.project.RestPmvInvocationHandler.executeWithIvyContext(RestPmvInvocationHandler.java:70)
    at ch.ivyteam.ivy.webserver.internal.rest.resource.project.RestPmvInvocationHandler.access$1(RestPmvInvocationHandler.java:65)
    at ch.ivyteam.ivy.webserver.internal.rest.resource.project.RestPmvInvocationHandler$PmvAwareInvocator.invoke(RestPmvInvocationHandler.java:50)
    ...
    at java.lang.Thread.run(Thread.java:748)

2 errors"

Is this issue still a known limitation even with the 7.0 LTS?

Thanks for your support!

Jack