of
>>> `onComplete` on a `Future` is `Unit`: the `onComplete` is synchronous but
>>> the callback is async.
>>>
>>> If you want your method to wait until the Druid call returns, you want
>>> to use `Future#transform` (
>>> https://www.sca
Scala is an expression oriented language, so the last thing you refer to is
returned.
def foo: Int = 3
returns 3. There is no need to use the return keyword, indeed its use can
complicate matters as you can create non-local returns, which I suspect is
what is confusing you in your example.
Tushar, this is a duplicate question. Please see the other one for a
response, and please try not to double post if possible, thanks!
On Wed, 8 May 2019 at 12:06, tushar pandit
wrote:
> Hi,
>
> I am trying to call function fetchFromDruid
>
> def main(args: Array[String]): Unit = {
> val res =
Tushar, this seems to be an issue with whatever Druid is. This mailing list
is for questions about Functional Programming in Scala, both in general and
more specifically the book with that title. If you ask your question in a
more relevant forum somebody may be able to provide you with an answer.
[
https://issues.apache.org/jira/browse/KAFKA-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16290245#comment-16290245
]
Jed Wesley-Smith commented on KAFKA-2260:
-
This would be a valuable feature, currently we need
\o/
thanks Kenji.
On 4 December 2016 at 00:20, Kenji Yoshida <6b656e6...@gmail.com> wrote:
> Hi everyone.
>
> scalaz 7.2.8 released!
>
> "org.scalaz" %% "scalaz-core" % "7.2.8"
>
> for Scala binary versions 2.10, 2.11 and 2.12.
>
> Thanks to all contributors.
> This is second maintenance
[
https://issues.apache.org/jira/browse/LOG4J2-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14107836#comment-14107836
]
Jed Wesley-Smith commented on LOG4J2-741:
-
@ianbarfield OOI, do you specify
[
https://issues.apache.org/jira/browse/LOG4J2-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074016#comment-14074016
]
Jed Wesley-Smith commented on LOG4J2-741:
-
I strongly consider the removal
[
https://issues.apache.org/jira/browse/LOG4J2-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074022#comment-14074022
]
Jed Wesley-Smith commented on LOG4J2-673:
-
Note that alternate language (like
[
https://issues.apache.org/jira/browse/LOG4J2-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074016#comment-14074016
]
Jed Wesley-Smith edited comment on LOG4J2-741 at 7/25/14 4:15 AM
[
https://issues.apache.org/jira/browse/LOG4J2-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14074072#comment-14074072
]
Jed Wesley-Smith commented on LOG4J2-741:
-
I don't know how you'd ask javac
think the type you talking about here is Optional? extends U instead
of ? extends OptionalU.
IIRC, Optional? extends U is not a subtype of OptionalU, just like any
other Collection class. ListChild is not a ListParent.
Cheers,
Henry
On Jul 13, 2013, at 3:15 AM, Jed Wesley-Smith j
? extends U
fn)
The problem is probably wide spread, and we need a tool to find these
mistakes.
Zhong Yu
On Sun, Jul 14, 2013 at 8:04 AM, Jed Wesley-Smith j...@wesleysmith.io
wrote:
(accidentally didn't post to the list)
You probably know that the example provided is not completed
, the extends part just doesn't matter.
You probably know that the example provided is not completed ported to
work with our Optional implementation, and fugue works around the type
system with Option as abstract class.
Cheers,
Henry
On Jul 13, 2013, at 4:35 PM, Jed Wesley-Smith
j
The ? extends Optional is unnecessary in flatMap as Optional is final.
interestingly enough, it actually is.
try the following test:
class OptionalTest {
class Parent {};
class Child extends Parent {};
@Test public void covariantReturn() {
OptionalParent some = some(new Parent());
ignore me, you do actually need both ? extends on the type constructor and
the inner type – dunno what I was thinking.
On 15 July 2013 13:02, Jed Wesley-Smith j...@wesleysmith.io wrote:
I'm not entirely sure that is a problem, have a look at the following:
https://gist.github.com/jedws
[
https://issues.apache.org/jira/browse/LOG4J2-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13615907#comment-13615907
]
Jed Wesley-Smith commented on LOG4J2-169:
-
Anything in particular holding up
information see previous posts on Optional forming a Monad.
cheers,
jed.
On 06/03/2013, at 10:58 PM, Remi Forax fo...@univ-mlv.fr wrote:
On 03/06/2013 11:54 AM, Jed Wesley-Smith wrote:
Really, this is a lot of fuss over nothing.
There is actually no fundamental difference between Scala's
Really, this is a lot of fuss over nothing.
There is actually no fundamental difference between Scala's Option, Guava's
Optional, Fugue's Option, Java's Optional and Haskell's Maybe – they are
modelling the same thing, the possibility of a value not being present.
The fact that there may be
[
https://issues.apache.org/jira/browse/LOG4J2-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587518#comment-13587518
]
Jed Wesley-Smith commented on LOG4J2-169:
-
Using a CopyOnWriteArrayList seems
[
https://issues.apache.org/jira/browse/LOG4J2-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587526#comment-13587526
]
Jed Wesley-Smith commented on LOG4J2-169:
-
I looked at this code last night
[
https://issues.apache.org/jira/browse/LOG4J2-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13587561#comment-13587561
]
Jed Wesley-Smith commented on LOG4J2-169:
-
What is bizarre?
Creating a new
[
https://issues.apache.org/jira/browse/LOG4J2-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jed Wesley-Smith updated LOG4J2-169:
Priority: Critical (was: Major)
ConfigurationFactory is not thread-safe
[
https://issues.apache.org/jira/browse/LOG4J2-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jed Wesley-Smith updated LOG4J2-169:
Summary: LogManager.getLogger doesn't work (was: ConfigurationFactory is
not thread-safe
Jed Wesley-Smith created LOG4J2-169:
---
Summary: ConfigurationFactory is not thread-safe
Key: LOG4J2-169
URL: https://issues.apache.org/jira/browse/LOG4J2-169
Project: Log4j 2
Issue Type
[
https://issues.apache.org/jira/browse/LOG4J2-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jed Wesley-Smith updated LOG4J2-169:
Labels: thread-safety (was: )
Description:
We randomly get the following
On Friday, 2 November 2012 07:02:38 UTC+11, fabrizio.giudici wrote:
… I'm a little worried
about a possible proliferation of multiple, incompatible libraries. I'd be
interested in knowing why Google rejected the patches submitted by
Atlassian (I interpret their comment as the fact
,
Jed Wesley-Smith
Versions: 2.0.0
Reporter: Jed Wesley-Smith
The class org.apache.struts2.views.freemarker.tags.TagModel creates a new
freemarker.template.DefaultObjectWrapper for each call to
unwrapParameters(Map). The problem is that that class is quite expensive to
construct as the super-class does
[
https://issues.apache.org/jira/browse/WW-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12877332#action_12877332
]
Jed Wesley-Smith commented on WW-3457:
--
Did you profile that ... ?
Yes, we saw
[
https://issues.apache.org/jira/browse/FELIX-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12869447#action_12869447
]
Jed Wesley-Smith commented on FELIX-2332:
-
Any update?
The m_extensions_cache
[
https://issues.apache.org/jira/browse/FELIX-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jed Wesley-Smith reopened FELIX-2332:
-
Sorry Karl, one more thing. In _removeExtensions(Object source) you still write
a blank
[
https://issues.apache.org/jira/browse/FELIX-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jed Wesley-Smith reopened FELIX-2332:
-
Lots of contention on ExtensionManager.openConnection(URL
[
https://issues.apache.org/jira/browse/FELIX-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12866464#action_12866464
]
Jed Wesley-Smith commented on FELIX-2332:
-
Karl, there are a couple of things I am
: Framework
Reporter: Jed Wesley-Smith
This method is synchronized, apparently to protect is the iteration through the
m_extensions list. We have seen significant blocking in our applications as
this lock encompasses the call to URL.openConnection as well.
As this list is rarely
[
https://issues.apache.org/jira/browse/FELIX-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jed Wesley-Smith updated FELIX-2332:
Attachment: ExtensionManager.java.patch
attached is a simple patch that reduces the scope
[
https://issues.apache.org/jira/browse/FELIX-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12765814#action_12765814
]
Jed Wesley-Smith commented on FELIX-1746:
-
Karl, there are a couple of things
[
https://issues.apache.org/jira/browse/FELIX-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12765817#action_12765817
]
Jed Wesley-Smith commented on FELIX-1746:
-
Question, you state that HotSpot
[
https://issues.apache.org/jira/browse/FELIX-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jed Wesley-Smith updated FELIX-1746:
Summary: Eliminate contention on
ServiceRegistry.getServiceReferences(String, Filter
[
https://issues.apache.org/jira/browse/FELIX-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12765374#action_12765374
]
Jed Wesley-Smith commented on FELIX-1746:
-
Karl, your patch reduces the contention
Type: Improvement
Components: Framework
Affects Versions: felix-2.0.0
Reporter: Jed Wesley-Smith
Performance testing has shown that there is significant contention on the
ServiceRegistry object's monitor during startup. This is caused by Spring DM
making lots of calls
[
https://issues.apache.org/jira/browse/FELIX-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jed Wesley-Smith updated FELIX-1746:
Attachment: blocked-threads.gif.jpg
jprofiler screenshot attached
Reduce contention
[
https://issues.apache.org/jira/browse/FELIX-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jed Wesley-Smith updated FELIX-1746:
Attachment: FELIX-1746.patch
Attached is a patch that adds a fully functional and tested
[
https://issues.apache.org/jira/browse/SHINDIG-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12736934#action_12736934
]
Jed Wesley-Smith commented on SHINDIG-1132:
---
Unfortunately, the problem
[
https://issues.apache.org/jira/browse/LUCENE-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12716118#action_12716118
]
Jed Wesley-Smith commented on LUCENE-1609:
--
We get hit by this too. We'd love
Versions: felix-1.2.1
Environment: Atlassian JIRA
Reporter: Jed Wesley-Smith
There is a memory leak caused by a strong reference from the
BundleProtectionDomain to a bundle and Felix.
The problem is that a URLClassLoader gets its AccessControlContext from the
stack
[
https://issues.apache.org/jira/browse/FELIX-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jed Wesley-Smith updated FELIX-1170:
Attachment: BundleProtectionDomain.java.FELIX-1170.patch
patch attached.
Note
[
https://issues.apache.org/jira/browse/FELIX-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711926#action_12711926
]
Jed Wesley-Smith commented on FELIX-1170:
-
The [Atlassian Plugins ticket|https
[
https://issues.apache.org/jira/browse/FELIX-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711926#action_12711926
]
Jed Wesley-Smith edited comment on FELIX-1170 at 5/21/09 7:22 PM
persists.
we are wondering if anyone has seen anyone has seen anything similar and
may have some advice.
cheers,
Jed Wesley-Smith
JIRA team @ Atlassian
* http://jira.atlassian.com/browse/JRA-16932
-
To unsubscribe, e-mail: users
Thanks Mike!
Michael McCandless wrote:
OK I'll add that (what IW does on setting an OOME) to the javadocs.
Mike
Jed Wesley-Smith wrote:
Mike,
regarding this paragraph:
To workaround this, on catching an OOME on any of IndexWriter's
methods, you should 1) forcibly remove the write lock
ahh, yes, sorry, the ability to read is occasionally handy... [wipes egg
off forehead]
cheers,
jed.
Michael McCandless wrote:
Actually, yes in 2.3.2: IndexReader.unlock has existed for a long time.
In 2.4.0, we moved this to IndexWriter.unlock.
Mike
Jed Wesley-Smith wrote:
not in 2.3.2
Michael McCandless wrote:
To workaround this, on catching an OOME on any of IndexWriter's
methods, you should 1) forcibly remove the write lock
(IndexWriter.unlock static method)
IndexWriter.unlock(*) is 2.4 only.
Use the following instead:
not in 2.3.2 though.
cheers,
jed.
Michael McCandless wrote:
Or you can use IndexReader.unlock.
Mike
Jed Wesley-Smith wrote:
Michael McCandless wrote:
To workaround this, on catching an OOME on any of IndexWriter's
methods, you should 1) forcibly remove the write lock
(IndexWriter.unlock
to discard it. I am suggesting that this could be
documented as it is not immediately obvious without coming across it and
debugging it. That being said, the VM is probably not that useful once
OOMEs are flying around anyway :-)
cheers,
jed.
Michael McCandless wrote:
Jed Wesley-Smith wrote
[
https://issues.apache.org/jira/browse/LUCENE-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12643360#action_12643360
]
Jed Wesley-Smith commented on LUCENE-1429:
--
Thanks Michael, I'll try and work out
All,
We have seen the following stacktrace in production with Lucene 2.3.2:
java.lang.IllegalStateException: abort() can only be called when
IndexWriter was opened with autoCommit=false
at org.apache.lucene.index.IndexWriter.abort(IndexWriter.java:2009)
at
Michael,
https://issues.apache.org/jira/browse/LUCENE-1429
Thanks mate. I'll try and work out the client handling policy of the
IndexWriter calls. I see that flush now aborts the transaction as well...
cheers,
jed.
Michael McCandless wrote:
Woops, you're right: this is a bug. I'll open
Wesley-Smith wrote:
Michael,
https://issues.apache.org/jira/browse/LUCENE-1429
Thanks mate. I'll try and work out the client handling policy of the
IndexWriter calls. I see that flush now aborts the transaction as
well...
cheers,
jed.
Michael McCandless wrote:
Woops, you're right
[
https://issues.apache.org/jira/browse/LUCENE-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12613018#action_12613018
]
Jed Wesley-Smith commented on LUCENE-1282:
--
Sun has posted their evaluation
[
https://issues.apache.org/jira/browse/LUCENE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463781
]
Jed Wesley-Smith commented on LUCENE-140:
-
Michael, Doron, you guys are legends!
Indeed the problem
[
https://issues.apache.org/jira/browse/LUCENE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jed Wesley-Smith updated LUCENE-140:
Attachment: indexing-failure.log
docs out of order
[
https://issues.apache.org/jira/browse/LUCENE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463440
]
Jed Wesley-Smith commented on LUCENE-140:
-
Hi Michael,
Thanks for the patch, applied and recreated
[
https://issues.apache.org/jira/browse/LUCENE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463470
]
Jed Wesley-Smith commented on LUCENE-140:
-
BTW. We have looked at all the open files referenced by the VM
[
https://issues.apache.org/jira/browse/LUCENE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463202
]
Jed Wesley-Smith commented on LUCENE-140:
-
Hi Michael,
This is awesome, I have prepared a patched 1.9.1
[
https://issues.apache.org/jira/browse/LUCENE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463203
]
Jed Wesley-Smith commented on LUCENE-140:
-
Alas, this doesn't appear to be the problem. We are still getting
[
https://issues.apache.org/jira/browse/LUCENE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462949
]
Jed Wesley-Smith commented on LUCENE-140:
-
We have now seen this in a number of customer sites since
[
https://issues.apache.org/jira/browse/LUCENE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462949
]
Jed Wesley-Smith commented on LUCENE-140:
-
We have now seen this in a number of customer sites since
[
https://issues.apache.org/jira/browse/LUCENE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462950
]
Jed Wesley-Smith commented on LUCENE-140:
-
and we also see ArrayIndexOutOfBoundsEx
[
https://issues.apache.org/jira/browse/LUCENE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462950
]
Jed Wesley-Smith commented on LUCENE-140:
-
and we also see ArrayIndexOutOfBoundsEx
[
http://issues.apache.org/jira/browse/LUCENE-748?page=comments#action_12459489 ]
Jed Wesley-Smith commented on LUCENE-748:
-
I guess, particularly in light of LUCENE-702 that this behavior is OK - and the
IndexReader.unlock(dir
[
http://issues.apache.org/jira/browse/LUCENE-748?page=comments#action_12459502 ]
Jed Wesley-Smith commented on LUCENE-748:
-
Awesome, thanks!
Exception during IndexWriter.close() prevents release of the write.lock
[
http://issues.apache.org/jira/browse/LUCENE-140?page=comments#action_12458669 ]
Jed Wesley-Smith commented on LUCENE-140:
-
We have seen this one as well. We don't have the same usage as above, we only
ever delete documents
[
http://issues.apache.org/jira/browse/LUCENE-140?page=comments#action_12458669 ]
Jed Wesley-Smith commented on LUCENE-140:
-
We have seen this one as well. We don't have the same usage as above, we only
ever delete documents
Issue Type: Bug
Affects Versions: 1.9
Environment: Lucene 1.4 through 2.1 HEAD (as of 2006-12-14)
Reporter: Jed Wesley-Smith
After encountering a case of index corruption - see
http://issues.apache.org/jira/browse/LUCENE-140 - when the close() method
encounters an exception
[
http://issues.apache.org/jira/browse/LUCENE-681?page=comments#action_12457253 ]
Jed Wesley-Smith commented on LUCENE-681:
-
worksforme
public class SerializationTest
{
public static void main(String[] args) throws Exception
All,
Just a quick question regarding the need to call Directory.close()
(actually for an FSDirectory) and whether it is really necessary. As far
as I can tell, the only implication of this is that the refCount is not
decremented and therefore the FSDirectory will persist for the life of
the
all,
We're just wondering if anyone has seen any exceptions when using the
IndexWriter.addDocument(...) or IndexReader.deleteDocuments(Term term)
methods apart from catastrophic IOExceptions (disk full/failed etc.).
Is it possible for instance that we may be able to create a document
that
Hello all,
We are upgrading from Lucene 1.4.3 to 1.9.1, and have many customers
with large existing index files. In our testing we have reused large
indexes created in 1.4.3 in 1.9.1 without incident. We have looked
through the changelog and the code and can't see any reason there should
be
79 matches
Mail list logo
