[jira] [Commented] (FILEUPLOAD-288) Linux dentry cache memory leak due to inappropriate temporary file detection

2017-11-22 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16263839#comment-16263839
 ] 

ASF GitHub Bot commented on FILEUPLOAD-288:
---

GitHub user fangwentong opened a pull request:

https://github.com/apache/commons-fileupload/pull/12

FILEUPLOAD-288: detect file only if the file written to disk.

see https://issues.apache.org/jira/browse/FILEUPLOAD-288

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/fangwentong/commons-fileupload master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-fileupload/pull/12.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #12


commit b28019b27ab06847815de02ed69fffdfa6bf18d1
Author: fangwentong 
Date:   2017-11-23T05:26:05Z

FILEUPLOAD-288: detect file only if the file written to disk.




> Linux dentry cache memory leak due to inappropriate temporary file detection
> 
>
> Key: FILEUPLOAD-288
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-288
> Project: Commons FileUpload
>  Issue Type: Improvement
> Environment: OS version: CentOS release 6.7 (Final)
> Kenel: 2.6.32-573.26.1.el6.x86_64
> JVM: Oracle 1.8.0_102-b14
> Tomcat: 8.0.33.0
> commons-fileupload : 1.3.3
>Reporter: fangwentong
>
> We use commons-fileupload:1.3.3 to handle multipart request, param 
> {{file-size-threshold}} was set to 200K. Our API handle multipart request in 
> high QPS, the size of request body is about 20KB, which means those parts was 
> saved in memory, not written to disk temporary file.
> But, in our production environment,  size of dentry cache grows up in high 
> speed. here are some analysis:
> in {{strace}} result, plenty of {{stat}} system call invoked for tmp files 
> which not exists. 
> {noformat}
> [pid 111310] <... stat resumed> {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0
> [pid 57844] <... stat resumed> 0x7f08e80b84b0) = -1 ENOENT (No such file or 
> directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624923.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624922.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624921.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624920.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624919.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624918.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 69798] stat("/tmp",  
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624917.tmp",  
> 
> [pid 69798] <... stat resumed> {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0
> [pid 57844] <... stat resumed> 0x7f08e80b84b0) = -1 ENOENT (No such file or 
> directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624916.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624915.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624914.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624913.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624912.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624911.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624910.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624909.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624908.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
> [pid 57844] 
> stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624907.tmp", 
> 0x7f08e80b84b0) = -1 ENOENT (No such file or directory)

[jira] [Created] (FILEUPLOAD-288) Linux dentry cache memory leak due to inappropriate temporary file detection

2017-11-22 Thread fangwentong (JIRA) 
fangwentong created FILEUPLOAD-288:
--

 Summary: Linux dentry cache memory leak due to inappropriate 
temporary file detection
 Key: FILEUPLOAD-288
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-288
 Project: Commons FileUpload
  Issue Type: Improvement
 Environment: OS version: CentOS release 6.7 (Final)
Kenel: 2.6.32-573.26.1.el6.x86_64
JVM: Oracle 1.8.0_102-b14
Tomcat: 8.0.33.0
commons-fileupload : 1.3.3
Reporter: fangwentong


We use commons-fileupload:1.3.3 to handle multipart request, param 
{{file-size-threshold}} was set to 200K. Our API handle multipart request in 
high QPS, the size of request body is about 20KB, which means those parts was 
saved in memory, not written to disk temporary file.

But, in our production environment,  size of dentry cache grows up in high 
speed. here are some analysis:

in {{strace}} result, plenty of {{stat}} system call invoked for tmp files 
which not exists. 
{noformat}
[pid 111310] <... stat resumed> {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0
[pid 57844] <... stat resumed> 0x7f08e80b84b0) = -1 ENOENT (No such file or 
directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624923.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624922.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624921.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624920.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624919.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624918.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 69798] stat("/tmp",  
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624917.tmp",  

[pid 69798] <... stat resumed> {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0
[pid 57844] <... stat resumed> 0x7f08e80b84b0) = -1 ENOENT (No such file or 
directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624916.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624915.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624914.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624913.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624912.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624911.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624910.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624909.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624908.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624907.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624906.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624905.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624904.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624903.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624902.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624901.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624900.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624899.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No such file or directory)
[pid 57844] 
stat("/tmp/upload_75a3e205_c3f1_43e7_8165_34f6a7a02227_518624898.tmp", 
0x7f08e80b84b0) = -1 ENOENT (No

[jira] [Commented] (IMAGING-207) Missing support for EXIF tags

2017-11-22 Thread Bruno P. Kinoshita (JIRA) 

[ 
https://issues.apache.org/jira/browse/IMAGING-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16263617#comment-16263617
 ] 

Bruno P. Kinoshita commented on IMAGING-207:


I think that is the last commit with "0x010e", the value for the image 
description.

Looking at the commits after that last one, it's possible to see new classes 
being created under the o.a.c.sanselan.formats.tiff.contants package. We can 
probably refer to a reference documentation, find out to which group the image 
description belongs to, and either update the class or create a new one under 
https://github.com/apache/commons-imaging/tree/62c8e6fe78529f410478d5830db32aa1ef7528da/src/main/java/org/apache/commons/imaging/formats/tiff/constants

How does that sound?

> Missing support for EXIF tags
> -
>
> Key: IMAGING-207
> URL: https://issues.apache.org/jira/browse/IMAGING-207
> Project: Commons Imaging
>  Issue Type: Improvement
>Reporter: Joakim
>Priority: Minor
>
> It seems Commons Imaging does not seem to support the following tags (which 
> are supported by Sanselan 0.97):
> ||Tag ID||Tag Name||Writable||Group||Values / Notes||TiffConstant in 
> Sanselan||
> |0x010e|ImageDescription|string|IFD0| |EXIF_TAG_IMAGE_DESCRIPTION|
> |0x9c9c|XPComment|int8u|IFD0| |EXIF_TAG_XPCOMMENT|
> https://sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IMAGING-207) Missing support for EXIF tags

2017-11-22 Thread Bruno P. Kinoshita (JIRA) 

[ 
https://issues.apache.org/jira/browse/IMAGING-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16263611#comment-16263611
 ] 

Bruno P. Kinoshita edited comment on IMAGING-207 at 11/23/17 12:25 AM:
---

Looks like it was removed still in Sanselan, in r13a8824 (`git log --patch 
13a8824`). Not too sure why. I guess the constants were going to be moved to 
their own classes? But maybe not everything was moved.

Found it by searching the tag in the git logs (instead of printing just 
commits, you can also use --patch and see the whole history).

{noformat}
$ git log --oneline -SEXIF_TAG_IMAGE_DESCRIPTION | awk '{print $1}'
13a8824
e5e9aec
f486f88
a3dfe07
5def112
{noformat}



was (Author: kinow):
Looks like it was removed still in Sanselan, in r13a8824 (`git log --patch 
13a8824`). Not too sure why. I guess the constants were going to be moved to 
their own classes? But maybe not everything was moved.

Found it by searching the tag in the git logs (instead of printing just 
commits, you can also use --patch and see the whole history).

$ git log --oneline -SEXIF_TAG_IMAGE_DESCRIPTION | awk '{print $1}'
13a8824
e5e9aec
f486f88
a3dfe07
5def112



> Missing support for EXIF tags
> -
>
> Key: IMAGING-207
> URL: https://issues.apache.org/jira/browse/IMAGING-207
> Project: Commons Imaging
>  Issue Type: Improvement
>Reporter: Joakim
>Priority: Minor
>
> It seems Commons Imaging does not seem to support the following tags (which 
> are supported by Sanselan 0.97):
> ||Tag ID||Tag Name||Writable||Group||Values / Notes||TiffConstant in 
> Sanselan||
> |0x010e|ImageDescription|string|IFD0| |EXIF_TAG_IMAGE_DESCRIPTION|
> |0x9c9c|XPComment|int8u|IFD0| |EXIF_TAG_XPCOMMENT|
> https://sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IMAGING-207) Missing support for EXIF tags

2017-11-22 Thread Bruno P. Kinoshita (JIRA) 

[ 
https://issues.apache.org/jira/browse/IMAGING-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16263611#comment-16263611
 ] 

Bruno P. Kinoshita commented on IMAGING-207:


Looks like it was removed still in Sanselan, in r13a8824 (`git log --patch 
13a8824`). Not too sure why. I guess the constants were going to be moved to 
their own classes? But maybe not everything was moved.

Found it by searching the tag in the git logs (instead of printing just 
commits, you can also use --patch and see the whole history).

$ git log --oneline -SEXIF_TAG_IMAGE_DESCRIPTION | awk '{print $1}'
13a8824
e5e9aec
f486f88
a3dfe07
5def112



> Missing support for EXIF tags
> -
>
> Key: IMAGING-207
> URL: https://issues.apache.org/jira/browse/IMAGING-207
> Project: Commons Imaging
>  Issue Type: Improvement
>Reporter: Joakim
>Priority: Minor
>
> It seems Commons Imaging does not seem to support the following tags (which 
> are supported by Sanselan 0.97):
> ||Tag ID||Tag Name||Writable||Group||Values / Notes||TiffConstant in 
> Sanselan||
> |0x010e|ImageDescription|string|IFD0| |EXIF_TAG_IMAGE_DESCRIPTION|
> |0x9c9c|XPComment|int8u|IFD0| |EXIF_TAG_XPCOMMENT|
> https://sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (COMMONSRDF-72) Pointers to containers (Graph/RDF)

2017-11-22 Thread Marco Brandizi (JIRA) 

 [ 
https://issues.apache.org/jira/browse/COMMONSRDF-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marco Brandizi updated COMMONSRDF-72:
-
Description: 
I'm writing a few utilities to ease the use of commons RDF, starting from a 
library I already have for Jena 
([here|https://github.com/marco-brandizi/rdfutils/blob/master/rdfutils-core/src/main/java/info/marcobrandizi/rdfutils/GraphUtils.java]
 the interface).

It would be quite useful to have container links in interfaces like Graph 
(Graph.getRDF()) or RDFTerm (RDFTerm.getGraph()). Methods that need to go back 
to their container to do something (e.g., add some property/value statement to 
a given IRI object, using the graph it comes from) wouldn't need to receive too 
many parameters (new triples would be added to subject.getGraph() and new IRI 
properties would be generated using subject.getGraph().getRDF() ).

Jena uses this approach (e.g., RDFNode has getModel() ).


  was:
I'm writing a few utilities to ease the use of commons RDF, starting from a 
library I already have for Jena 
([here|https://github.com/marco-brandizi/rdfutils/blob/master/rdfutils-core/src/main/java/info/marcobrandizi/rdfutils/GraphUtils.java]
 the interface).

It would be quite useful to have container links in interfaces like Graph 
(Graph.getRDF()) or RDFTerm (RDFTerm.getGraph()). Methods that need to go back 
to their container to do something (e.g., add some property/value statement to 
a given IRI object, using the graph it comes from) wouldn't need to receive too 
many parameters (new triples would be added to subject.getGraph() and new IRI 
properties would be generated using subject.getGraph().getRDF() ).



> Pointers to containers (Graph/RDF)
> --
>
> Key: COMMONSRDF-72
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-72
> Project: Apache Commons RDF
>  Issue Type: New Feature
>  Components: api
>Reporter: Marco Brandizi
>
> I'm writing a few utilities to ease the use of commons RDF, starting from a 
> library I already have for Jena 
> ([here|https://github.com/marco-brandizi/rdfutils/blob/master/rdfutils-core/src/main/java/info/marcobrandizi/rdfutils/GraphUtils.java]
>  the interface).
> It would be quite useful to have container links in interfaces like Graph 
> (Graph.getRDF()) or RDFTerm (RDFTerm.getGraph()). Methods that need to go 
> back to their container to do something (e.g., add some property/value 
> statement to a given IRI object, using the graph it comes from) wouldn't need 
> to receive too many parameters (new triples would be added to 
> subject.getGraph() and new IRI properties would be generated using 
> subject.getGraph().getRDF() ).
> Jena uses this approach (e.g., RDFNode has getModel() ).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #309: Fix EventCountCircuitBreaker increment batch

2017-11-22 Thread kinow 
Github user kinow commented on the issue:

https://github.com/apache/commons-lang/pull/309
  
I'll leave the ticket open for a while other to be able to review it too. 
And before merging I'll have to create a place holder ticket in JIRA. Or if you 
have time and would like to do that :-) otherwise I'll do as it takes just a 
couple of minutes to create and link to this PR.


---

[jira] [Commented] (IMAGING-207) Missing support for EXIF tags

2017-11-22 Thread Joakim Knudsen (JIRA) 

[ 
https://issues.apache.org/jira/browse/IMAGING-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16263344#comment-16263344
 ] 

Joakim Knudsen commented on IMAGING-207:


Well, maybe the tags have been moved? I'm referring to 
https://commons.apache.org/proper/commons-imaging/javadocs/api-release/org/apache/sanselan/formats/tiff/constants/ExifTagConstants.html

vs 

https://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/formats/tiff/constants/ExifTagConstants.html

> Missing support for EXIF tags
> -
>
> Key: IMAGING-207
> URL: https://issues.apache.org/jira/browse/IMAGING-207
> Project: Commons Imaging
>  Issue Type: Improvement
>Reporter: Joakim Knudsen
>Priority: Minor
>
> It seems Commons Imaging does not seem to support the following tags (which 
> are supported by Sanselan 0.97):
> ||Tag ID||Tag Name||Writable||Group||Values / Notes||TiffConstant in 
> Sanselan||
> |0x010e|ImageDescription|string|IFD0| |EXIF_TAG_IMAGE_DESCRIPTION|
> |0x9c9c|XPComment|int8u|IFD0| |EXIF_TAG_XPCOMMENT|
> https://sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #309: Fix EventCountCircuitBreaker increment batch

2017-11-22 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/309
  

[![Coverage 
Status](https://coveralls.io/builds/14330917/badge)](https://coveralls.io/builds/14330917)

Coverage remained the same at 95.168% when pulling 
**835432cec0687668abe8aedf186e99e414dc20e3 on 
dieb:dieb/fix-count-cb-bigger-increment** into 
**6049e77fdcd021544a60651fc6de4d80e2ef1c2d on apache:master**.



---

[GitHub] commons-lang issue #309: Fix EventCountCircuitBreaker increment batch

2017-11-22 Thread dieb 
Github user dieb commented on the issue:

https://github.com/apache/commons-lang/pull/309
  
Should be good now. Thanks!


---

[GitHub] commons-lang issue #309: Fix EventCountCircuitBreaker increment batch

2017-11-22 Thread dieb 
Github user dieb commented on the issue:

https://github.com/apache/commons-lang/pull/309
  
Hey @kinow, thank you for reviewing. Can you hold it off for a moment? Just 
realized the javadoc is incomplete, updating it right now.


---

[jira] [Commented] (IMAGING-207) Missing support for EXIF tags

2017-11-22 Thread Sebb (JIRA) 

[ 
https://issues.apache.org/jira/browse/IMAGING-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16263297#comment-16263297
 ] 

Sebb commented on IMAGING-207:
--

Seems odd, given that Imaging is the same as Sanselan + some fixes.
It's not a rewrite. But I suppose something could have been lost.

> Missing support for EXIF tags
> -
>
> Key: IMAGING-207
> URL: https://issues.apache.org/jira/browse/IMAGING-207
> Project: Commons Imaging
>  Issue Type: Improvement
>Reporter: Joakim Knudsen
>Priority: Minor
>
> It seems Commons Imaging does not seem to support the following tags (which 
> are supported by Sanselan 0.97):
> ||Tag ID||Tag Name||Writable||Group||Values / Notes||TiffConstant in 
> Sanselan||
> |0x010e|ImageDescription|string|IFD0| |EXIF_TAG_IMAGE_DESCRIPTION|
> |0x9c9c|XPComment|int8u|IFD0| |EXIF_TAG_XPCOMMENT|
> https://sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #309: Fix EventCountCircuitBreaker increment batch

2017-11-22 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/309
  

[![Coverage 
Status](https://coveralls.io/builds/14329426/badge)](https://coveralls.io/builds/14329426)

Coverage remained the same at 95.168% when pulling 
**f00803140ee53875da470a2ffaf5928d66f3f1fb on 
dieb:dieb/fix-count-cb-bigger-increment** into 
**6049e77fdcd021544a60651fc6de4d80e2ef1c2d on apache:master**.



---

[GitHub] commons-lang issue #309: Fix EventCountCircuitBreaker increment batch

2017-11-22 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/309
  

[![Coverage 
Status](https://coveralls.io/builds/14329343/badge)](https://coveralls.io/builds/14329343)

Coverage remained the same at 95.168% when pulling 
**f9a4bef179887b032c9338af42ea697f457d4e14 on 
dieb:dieb/fix-count-cb-bigger-increment** into 
**6049e77fdcd021544a60651fc6de4d80e2ef1c2d on apache:master**.



---

[jira] [Created] (COMMONSRDF-72) Pointers to containers (Graph/RDF)

2017-11-22 Thread Marco Brandizi (JIRA) 
Marco Brandizi created COMMONSRDF-72:


 Summary: Pointers to containers (Graph/RDF)
 Key: COMMONSRDF-72
 URL: https://issues.apache.org/jira/browse/COMMONSRDF-72
 Project: Apache Commons RDF
  Issue Type: New Feature
  Components: api
Reporter: Marco Brandizi


I'm writing a few utilities to ease the use of commons RDF, starting from a 
library I already have for Jena 
([here|https://github.com/marco-brandizi/rdfutils/blob/master/rdfutils-core/src/main/java/info/marcobrandizi/rdfutils/GraphUtils.java]
 the interface).

It would be quite useful to have container links in interfaces like Graph 
(Graph.getRDF()) or RDFTerm (RDFTerm.getGraph()). Methods that need to go back 
to their container to do something (e.g., add some property/value statement to 
a given IRI object, using the graph it comes from) wouldn't need to receive too 
many parameters (new triples would be added to subject.getGraph() and new IRI 
properties would be generated using subject.getGraph().getRDF() ).




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #309: Fix EventCountCircuitBreaker increment batch

2017-11-22 Thread dieb 
GitHub user dieb opened a pull request:

https://github.com/apache/commons-lang/pull/309

Fix EventCountCircuitBreaker increment batch

Fixes #incrementAndCheckState(Integer increment) by passing the increment 
downstream.

I wasn't very sure which additional tests should be added, open to 
suggestions.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dieb/commons-lang 
dieb/fix-count-cb-bigger-increment

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/309.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #309


commit f9a4bef179887b032c9338af42ea697f457d4e14
Author: Andre Dieb 
Date:   2017-11-22T18:44:23Z

Fix EventCountCircuitBreaker increment batch

Fixes #incrementAndCheckState(Integer increment) by passing the increment 
downstream.




---

[jira] [Created] (VFS-649) SMB v. 2 / 3 integration based on SMBJ

2017-11-22 Thread JIRA 
André Hauenstein created VFS-649:


 Summary: SMB v. 2 / 3 integration based on SMBJ
 Key: VFS-649
 URL: https://issues.apache.org/jira/browse/VFS-649
 Project: Commons VFS
  Issue Type: New Feature
Affects Versions: 2.2
Reporter: André Hauenstein
Priority: Minor


Hi,

based on this issue: [https://issues.apache.org/jira/browse/VFS-635] I created 
an implementation of [https://github.com/hierynomus/smbj] into vfs 2.2

I named the provider SMB2, so the scheme I used is also smb2. I dont know if 
it's better to rename the existing smb to cifs and use smb for the smb v2+ 
implementation.

All the tests from the ProviderTests pass but I had to remove the test (exclude 
in pom.xml) because the test needs an external smb share.

Thanks for any feedback or further advice how to proceed with this pr,
André



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)