Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: NullPointerException on pipelines with transforms receiving more than one flow in input #3056

Closed
sramazzina opened this issue Jul 6, 2023 · 4 comments
Assignees
Labels
Milestone

Comments

@sramazzina
Copy link
Contributor

sramazzina commented Jul 6, 2023

Apache Hop version?

2.5.0 and any previous version

Java version?

openjdk-11

Operating system

Linux

What happened?

We are experiencing a NullPointerException on pipelines where we have transforms that receives as input more than one flow.
Let me summarize below some of the point that could be interesting for our investigation:

  • The problem always happen when we have two flows as input of a transform.
  • The problem always happen at the very beginning of the processRow method and is always related to code where the getInputRow() method is involved in a complex inline instruction (like data.fieldnrs[i] = getInputRowMeta().indexOfValue(meta.getFieldName()[i]); or data.outputRowMeta = getInputRowMeta().clone();) and that method returns null
  • The problem randomly happens 2 or 3 times (lastly it is this way) per day sometimes or nothing at all for a long time then it apperas again

The fact that is a random problem makes it hard to reproduce and for this reason till now we were unable to catch it. We asked the customer some context data and we got the confirmation that the overall load of the server at the time of the issue is normal. The system isn't under severe stress

I post here some screenshots of the pipeline by putting in evidence the transforms that gives the issue

image

image

image

Issue Priority

Priority: 1

Issue Component

Component: Transforms

@github-actions github-actions bot added P1 Critical Issue Transforms labels Jul 6, 2023
@sramazzina sramazzina self-assigned this Jul 6, 2023
sramazzina added a commit to sramazzina/hop that referenced this issue Jul 6, 2023
@sramazzina sramazzina mentioned this issue Jul 6, 2023
5 tasks
@sramazzina sramazzina added this to the 2.6 milestone Jul 6, 2023
sramazzina added a commit to sramazzina/hop that referenced this issue Jul 21, 2023
@hansva hansva modified the milestones: 2.6, 2.7 Sep 1, 2023
sramazzina added a commit to sramazzina/hop that referenced this issue Sep 8, 2023
@sramazzina
Copy link
Contributor Author

sramazzina commented Sep 8, 2023

After months of tries looking for a reproduction path we definitely were able to get it. So let me try to write down something interesting to share with the community so that we can try to elaborate on this.

First thing first. We were able to reproduce the problem by putting the system under light load (that means if we evaluate the 5min load average on linux system we are considering load > 2). We also already said that this happens only for pipelines where we have more than one hop that is entering a target transform.

Therefore

  • because we started thinking the problem was related in how the BaseTransform.handleGetRow(), I rebuilt the hop-engine module by adding a bunch of log messages in points of the method that I considered critical. I thought it was a good idea to decorate every log message with a bunch of context information to understand better what was happening at the time of the exception
  • we put together a very simple test pipeline

image

As I said the issue randomly happens but after waiting for a while it happened. It is not clear yet were the problem is but it happened. I though it was a good idea start talking about that so I wanted to share everything till now. I attached to this comment the sample pipeline and the two logs related to a good and a failed execution. If someone want to help in investigating about that I'm very happy for that. You can also take a look at the changes made to handleGetRow to get the added log messages here sramazzina@f17fbf5

Remember that this issue was inherited from Kettle because we incurred into this also at the time we were using it.

I will be back soon with other comments, let me go back to work hard on solving this issue.

testNullPointer.hpl.zip

logfile-20230908-1642-ok.log

logfile-20230908-1642-ko.2.log

logfile-20230908-1642-ko.1.log

sramazzina added a commit to sramazzina/hop that referenced this issue Sep 29, 2023
sramazzina added a commit to sramazzina/hop that referenced this issue Sep 29, 2023
@mattcasters mattcasters self-assigned this Nov 16, 2023
@mattcasters
Copy link
Contributor

I ran hundreds of thousands of iterations of the simple test (see above testNullPointer.hpl) without a reproduction.

Running on Ubuntu 22.04.3 LTS:

openjdk version "11.0.20.1" 2023-08-24
OpenJDK Runtime Environment (build 11.0.20.1+1-post-Ubuntu-0ubuntu122.04)
OpenJDK 64-Bit Server VM (build 11.0.20.1+1-post-Ubuntu-0ubuntu122.04, mixed mode, sharing)

Can you let me know which Run Configuration you're using to reproduce, its settings?

@mattcasters
Copy link
Contributor

Tests running at around 1200% CPU (100% on 12 cores).

@hansva hansva modified the milestones: 2.7, 2.8 Nov 17, 2023
@mattcasters
Copy link
Contributor

Reproduction path for me: run the following loop in 5 terminals and wait a few hours. One or more of the terminal tabs will be titled "sleep" and they'll show the NPE stack trace:

while true; do

  sh hop-run.sh -e "hop2 local" -f issue-3056/testNullPointer.hpl -r local
  if [ "$?" -ge 1 ]; then
    echo "Exit after exit code $?" 
    sleep 9999999
    break
  fi

done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants